Re: [boost] asio formal review - demuxer

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-30 01:58:38

--- Darryl Green <darryl.green_at_[hidden]> 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