Rene Rivera wrote: [snip]
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 memory...
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. [runs 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 new demuxer_service. 3) demuxer_service::demuxer_service calls get_service<win_iocp_demuxer_service> 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 list.
2) the demuxer also has a PIMPL relation with demuxer_service, and demuxer_service has a PIMPL relation with win_iocp_demuxer_service
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.