Hi Matt, --- Matt Vogt <mattvogt@warpmail.net> wrote:
- demuxer::run() overload that takes a timeout (possibly two overloads, one taking an absolute time and the other taking a duration) which means it will run for that long regardless of how much work it performs.
I think this is sensible.
For now, I am just going to look at doing the above plus having an enum return value from run() indicating "interrupted", "out_of_work", "timed_out", etc. I think these changes have obvious utility, provided I can get the semantics correct and unsurprising. If you pass a timeout of zero i'm going to make it only extract and execute handlers from the queue while the system clock remains unchanged. This will prevent the problem you described where additional handlers being queued might make the run function never return. Also to clarify my original statement about running for that long regardless of how much work it performs: I think it should not wait until the timeout if there is no work to be performed. If no work is pending (i.e. there are no async operations in progress) it should return immediately. This is how the current run() function works, where it has an implicit infinite timeout. <snip>
A possible scenario is one using the same GUI system, where a pool of threads process IO events. If only one thread can update the GUI, then operations which result in an update of the GUI would have to be dispatched out of the thread pool, so that the main thread will handle them. Handlers not changing the GUI could be dispatched within the thread pool.
Would this design call for two demuxers?
You could do it with two demuxers, yes (with changes proposed above). Basically whenever you're ready to have a handler dispatched to the main thread's demuxer, you can either post it direct to that demuxer, or when you initiate the operation wrap the handler so that it goes to the main thread demuxer, e.g.: async_read(s, bufs, main_thread_demuxer.wrap(handler)); An alternative could be some implementation of the Dispatcher concept for dispatching into a windows message loop. This has been discussed in some other posts. Cheers, Chris