Re: [boost] asio formal review begins

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