Re: [boost] Asio formal review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-15 16:53:09

Hi Simon,

--- simon meiklejohn <simon_at_[hidden]> wrote:
> From a closer reading of the documents i gather that
> a call to locking_dispatcher.post( func ) is required 
> to NOT execute func() immediately. (i.e. it puts the request
> in the underlying demuxer queue).

Yes, although I would word it slightly differently: a call to
post() is required to *guarantee* that func() is not executed
immediately.

<snip>
> Perhaps you've given one elsewhere, but a description of
> exactly when func() gets called in a range of scenario might be
> nice.
> 
> e.g. for method() in [post,dispatch]
> if locking_dispatcher.method( func ) called from
> 1. a foreground thread (no demuxer::run() called)
> 2. a thread in demuxer::run()
> 3. ditto, that is currently executing another handler requested
> through a different locking_dispatcher
> 4. ditto, executing another handler requested through the
> same locking_dispatcher.

First, lets review the guarantees made by the demuxer and
locking dispatcher in respect of when handlers are executed:

- The demuxer will only execute a handler from within a call to
  demuxer::run().

- The locking dispatcher will only execute a handler when no
  other handler for the same locking dispatcher is executing,
  in addition to the associated demuxer's guarantee (i.e. to
  only execute the handler within a call to demuxer::run()).

I'll add these sort of examples to the locking_dispatcher doc, but here
it is now:

1. Foreground thread (no demuxer::run() called):

1.a. locking_dispatcher::post() always puts the handler on the
queue, since post() will never execute the handler immediately.

1.b. locking_dispatcher::dispatch() puts the handler in the
queue, since the locking_dispatcher's guarantee cannot be met.

2. A thread in demuxer::run():

2.a. locking_dispatcher::post() always puts the handler on the
queue, since post() will never execute the handler immediately.

2.b. locking_dispatcher::dispatch() will execute the handler
immediately if no other handler for the same locking dispatcher
is currently executing. The demuxer's guarantee is already met.

3. A handler requested through a different locking dispatcher:

3.a. locking_dispatcher::post() always puts the handler on the
queue, since post() will never execute the handler immediately.

3.b. locking_dispatcher::dispatch() will execute the handler
immediately if no other handler for the same locking dispatcher
is currently executing. The demuxer's guarantee is already met.
Handlers dispatched through other locking dispatchers have no
effect.

4. A handler requested through the same locking dispatcher:

4.a. locking_dispatcher::post() always puts the handler on the
queue, since post() will never execute the handler immediately.

4.b. locking_dispatcher::dispatch() will not execute the handler
immediately since the locking_dispatcher's guarantee cannot be
met. That is, a handler for the same locking dispatcher is
already executing (i.e. the one we're in).

> Is this behaviour something that varies between platforms
> (demuxer service implemenations)?

No. It's the same everywhere.

Cheers,
Chris