--- Darryl Green <darryl.green@myrealbox.com> wrote: <snip>
It is documented that (unlike facets of a locale) the services are constructed on use. This means that there is no way (?) that a custom replacement service can be provided via the demuxer, as the actual construction of the service is done by the service_factory based on the type of service requested from the demuxer.
Service construction can be customised by specialising the service_factory template, and then calling get_service e.g.: demuxer.get_service(service_factory<my_service>(...)); The "standard" services in the public interface are not intended for customisation in this way. However this facility can be used for user-defined services. Note: this service_factory template was introduced originally to allow the get_service member template to work with MSVC6.
Hence, to customize the service, it has to have a different type from any existing service, and the user of the service has to be modified to use the new type. There is a possibility that some services are used by multiple components (eg the demuxer and the socket) so care is needed in doing this customization. Basically about as unlike a local and facets as you can get? I think this is what threw me to start with.
Did I get that right?
The thing that makes a facet in a locale replaceable by a derived facet implementation is that the facet itself has overrideable virtual functions. It is not an attribute of the locale object, as far as I know, that determines whether a facet is replaceable. Yes it's true that the services in asio's public interface are not replaceable, as these services do not have virtual functions for reasons discussed extensively elsewhere. :) However other services could be added by the user which do. If you don't feel the comparison to locale is useful, that's fine, as it was just intended as an aid to understanding the design. I guess when I drew the comparison (which I still think is apt) I was thinking of different aspects of the way locale works. <snip>
I've had a look at that now. Is there some particularly profound reason why logging implemented to fit in with the service idiom is a good thing/example?
It aims to demonstrate how socket operations can be customised, in this case to add debugging information. Obviously the log itself is shared between all socket instances.
It seems to achieve nothing special, though it goes through some hoops to create a demuxer (private to the logging service) to perform work in a background thread? Is that supposed to illustrate something? I think this relates back to the need for better docs/concepts in this area.
The demuxer is being used as a thread-safe work queue. I agree this could be explained better in the example. Cheers, Chris