Chris wrote
Yes, although I would word it slightly differently: a call to post() is required to *guarantee* that func() is not executed immediately. [SNIP] 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: [SNIP]
Thats great thanks. I appreciate that the behaviour described is sufficiently specified by the guarantees given for dispatcher and lock_dispatcher, but for us slow ones it helps to be led through it. Incorporating your comments into the docs would be very useful. The one other degenerate case i guess is if post or dispatch are called from a foreground thread and no thread ever calls demuxer::run, then the handler simply wont be called. One final concern i had is about use of asio in multiple static libs linked into a final application. (An example that would come up in my work in VOIP would be separate libs for media streaming using udp/rtp, SIP protocol using tcp or udp, application networking on tcp, logging to file etc) Are there issues with this setup? Would there end up being some per lib static objects/threads, or could i call demuxer::run from a single point in the app and have it service i/o throughout the app? I probably should be able to figure this out from the source, but when i drill down through the code the answer eludes me. Cheers Simon