|
Boost : |
From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-10 19:12:39
Hi Simon,
--- simon meiklejohn <simon_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk