Re: [boost] Asio formal review

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-15 00:06:21

Hi Chris and Matthew,

>> > I don't really follow the intent of the locking dispatcher.
>> > It appear to me that it simply achieves the same effect as
>> > adding a scoped lock to each dispatched method (each using the
>> > same mutex).
>> 
>> It's not quite the same thing. A scoped lock in each dispatched
>> handler means that the method may be blocked while waiting to
>> acquire the mutex. A blocked handler means that other handlers
>> may also be prevented from executing even though they are ready
>> to go.
>> 
>> The locking_dispatcher ensures that the handler won't even be
>> dispatched until the lock is acquired. This means that the
>> execution of other handlers can continue unimpeded.

>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).

Is that the case? 

If its not so, then what occurs when you call 
locking_dispatcher.post( func ) from a thread that has not
called demuxer::run().

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.

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

Thanks again

Simon