Hi Simon, --- simon meiklejohn <simon@simonmeiklejohn.com> wrote:
Not a full review, though i will submit one. Just wanting to reiterate my view that the asio::demuxer could use a modification to support a customisation for Handler execution on the win32 message pump.
I'm not sure what's the best way to do this in the context of the existing asio code - but some way to hook into the work queueing mechanism would be required.
I'm of the opinion that asio::demuxer isn't the right place for this. Instead it should be an implementation of the Dispatcher concept.
Alternatively, all the api calls that currently take a boost::asio::demuxer& could instead take a more abstract base class so entirely custom thread mechansims could be used, derived from that base class.
But the primary purpose of the demuxer is as an I/O demultiplexer, so the way it uses threads is aimed specifically at that use case, and it's not really suitable for customisation in the way you describe. I think the appropriate place to choose how the handler should be delivered is the point where an asynchronous operation is started. For example: async_read(socket, buffers, locking_dispatcher.wrap(handler)); says that I want the handler to be invoked via the specified dispatcher object. In a multithreaded application you are likely to want different locking_dispatchers for different application-level objects, even though all share the same demuxer. Cheers, Chris