From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-10 20:45:15
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