Re: [boost] Asio formal review

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-21 14:24:23

----- Original Message ----- 
From: "Christopher Kohlhoff" <chris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, December 21, 2005 11:59 AM
Subject: Re: [boost] Asio formal review

> Hi Simon,
> 
> --- simon meiklejohn <simon_at_[hidden]> 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