Re: [boost] Asio formal review

From: Matt Vogt (mattvogt_at_[hidden])
Date: 2005-12-19 21:15:25

Christopher Kohlhoff <chris <at> kohlhoff.com> writes:

> 

Hi Chris, sorry if this reply turns up twice; my internet access is borked and
I'm having fun with GMANE...

> I have pondered this from time to time, but haven't been able to
> decide on the ideal interface. Here are some of the candidates:
> 
> - demuxer::run() overload that takes a timeout (possibly two
>   overloads, one taking an absolute time and the other taking a
>   duration) which means it will run for that long regardless of
>   how much work it performs.

I think this is sensible.

> - demuxer::perform_work() function that runs until it has
>   performed exactly one item of work.
> 
> - demuxer::perfork_work() function that takes a timeout and runs
>   until the time has elapsed or it performs one item of work.

I don't see the relevance of performing one unit of work.
I think my preferred model model might be to queue up events that need to be
handled, and to process all previously queued events during a call to 
perform_work.  New items should not be added to the queue that is being 
processed during the perform_work call, or the call may never return...

With this function, my theoretical GUI app which must process the handlers in 
the main thread would use a timer to priodically process IO events.  I think 
this would give a more deterministic result than relying on idle processing.

> The problems I ran into when thinking about this include:
> 
> - How to tell that the demuxer has finished all its work?
>   Boolean return value from the above functions? Is it better
>   for true to mean its done or that it has more to do?

Use an enum for the return code?

> - What happens with multiple thread calling these functions?
>   What is the correct interaction between these functions and
>   demuxer::interrupt() and demuxer::reset()? Do we need an
>   additional return value from run()/perform_work() that means
>   the demuxer was interrupted?

Sorry, I don't understand the situations in which one would use interrupt and
reset, so I can't comment on how they're affected.

Also, multi-threaded apps would be a different kettle of fish.  Why would
multiple threads each want to process an arbitrary subset of pending events?

A possible scenario is one using the same GUI system, where a pool of threads
process IO events.  If only one thread can update the GUI, then operations
which result in an update of the GUI would have to be dispatched out of the
thread pool, so that the main thread will handle them.  Handlers not changing
the GUI could be dispatched within the thread pool.

Would this design call for two demuxers? Or is it not workable in asio?

Matt