----- Original Message ----- From: "Christopher Kohlhoff" <chris@kohlhoff.com> To: <boost@lists.boost.org> Sent: Wednesday, December 21, 2005 11:59 AM Subject: Re: [boost] Asio formal review
Hi Simon,
--- simon meiklejohn <simon@simonmeiklejohn.com> wrote:
Wouldnt this problem be solved more naturally if an interface were exposed out of the demuxer for signalling the availability of more work as it arrives? The GUI thread could then be made to call back into demuxer::run only when appropriate rather than busily during idle time.
Bit of a chicken-and-egg issue there. You don't want to call demuxer::run unless there's work to do, but you can't know if there's work to do unless you call demuxer::run to dequeue events from the OS's event demultiplexer :)
This sort of use case is probably better solved using your proposed windows message pump dispatcher, but I can also see a use for short, timed invocations of demuxer::run.
Thinking a little bit more on this. Isnt it true that the asio library is essentially looking at what platform its compiled for and self-configuring for the optimal needs of that platform. Thats great for the main use cases - but platforms like windows are essentially a hybrid of gui architecture + 'console' architecture and you have chosen the 'console' side as giving higher throughput. I'd heartily agree that the gui environment on win32 is far from optimal from a performance perspective (i.e. windows messages per io operation sucks). However we're not always interested in high performance - sometimes what we'd prefer is a better mating to the gui platform. i.e. a demuxer implementation that can trade performance for architectural simplicity. i.e. inject the message pump as a delivery mechanism into a specialisation of demuxer. A naive approach (i.e. all that comes to mind for me) would be to add a virtual method to demuxer. Where currently demuxer is calling the Handler directly, instead pass it to the virtual function 'deliver_handler( Handler& handler )'. Then someone who wants gui delivery can create a class derived from asio::demuxer typedef, override deliver_handler manage their own internal queue of Handlers and create a cross-thread notification mechanism appropriate to the platform The virtual function would impose a cost on all platforms so perhaps a special purpose demuxer base class could be created (special policy perhaps) intended for derivation. e.g. asio::forwarding_demuxer Cheers Simon