Simon said
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. [SNIP]
Chris said
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. [SNIP] 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));
And following that model, async_read(socket, buffers, win32_pump_dispatcher.wrap(handler)); I agree that would work, so maybe thats good enough. (By which i mean, very good, like the rest of the lib :) However, locking_dispatcher has fairly simple innards, and a win32_pump_dispatcher would require an implementation thats a lot like asio::demuxer -i.e. with an internal queue of Handlers. Opportunity for re-use?
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 can't see anything in the demuxer interface which limits it purely this role. Its applicability seems entirely general. (abstracted deferral of Handlers, which in reality can be 'handling' anything). In a program that mixes asio with other callback-originating libraries its attractive to extend the asio thread model to those other libraries as well. Thanks again Simon