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