Hi Simon, --- simon meiklejohn <simon@simonmeiklejohn.com> 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