Re: [boost] Asio formal review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-19 22:15:10

Hi Matt,

--- Matt Vogt <mattvogt_at_[hidden]> wrote:
> > - 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.

For now, I am just going to look at doing the above plus having
an enum return value from run() indicating "interrupted",
"out_of_work", "timed_out", etc. I think these changes have
obvious utility, provided I can get the semantics correct and
unsurprising.

If you pass a timeout of zero i'm going to make it only extract
and execute handlers from the queue while the system clock
remains unchanged. This will prevent the problem you described
where additional handlers being queued might make the run function
never return.

Also to clarify my original statement about running for that
long regardless of how much work it performs: I think it should
not wait until the timeout if there is no work to be performed.
If no work is pending (i.e. there are no async operations in
progress) it should return immediately. This is how the current
run() function works, where it has an implicit infinite timeout.

<snip>
> 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?

You could do it with two demuxers, yes (with changes proposed
above). Basically whenever you're ready to have a handler
dispatched to the main thread's demuxer, you can either post it
direct to that demuxer, or when you initiate the operation wrap
the handler so that it goes to the main thread demuxer, e.g.:

  async_read(s, bufs,
      main_thread_demuxer.wrap(handler));

An alternative could be some implementation of the Dispatcher
concept for dispatching into a windows message loop. This has
been discussed in some other posts.

Cheers,
Chris