From: Andrew Schweitzer (a.schweitzer.grps_at_[hidden])
Date: 2005-12-27 16:56:43
Rene Rivera wrote:
> Andrew Schweitzer wrote:
>>I think the library design or naming might be a bit confused on this
>>point (or quite possibly it's me).
> The fact that it's confusing, even when looking at the code, is a point
> against the design ;-) OK, I'm rereading the code, instead of relying on
Yes, although I think I'd say maybe it's not a design issue but just
that the documentation isn't as complete as the code.
>>As far as I can tell two things are true:
>> 1) the demuxer ends up with two actual services in its list after it
>> is constructed:
>> a) demuxer_service
>> b) win_iocp_demuxer_service (or the selected
>> platform-implemenation of demuxer_service)
> OK, AFAICT it only ends up with (b) in the service_registry.
Ok, time for debugger.
I think it's a and b. VC7.1 debugger appears to show that
service_registry_.first_service_ points at a demuxer_service, and the
demuxer_service's node's next_ member points at win_iocp_demuxer_service.
I think here's how the code works:
1) demuxer::demuxer calls get_service<demuxer_service>
2) get_service finds nothing in the service_registry_, so it creates a
3) demuxer_service::demuxer_service calls
4) get_service doesn't find a win_iocp_demuxer_service in
service_registry_, so it creates a new one, and adds it. It returns.
5) demuxer_service::demuxer_service returns
6) the first call to get_service now adds the new demuxer_service to the
>> 2) the demuxer also has a PIMPL relation with demuxer_service,
>> and demuxer_service has a PIMPL relation with
> Yes. I guess the key point here is that there's only 1 (singleton) of
> win_iocp_demuxer_service for all demuxer_service instances in the same
> basic_demuxer instance? (again AFAICT)
Yes I think there's only one win_iocp_demuxer_service, within that
particular instance of the demuxer. I think get_servive<ServiceType>
guarantees there's only one list member of a given ServiceType, by using
the language's typeid operator.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk