
Hi Simon, --- simon meiklejohn <simon@simonmeiklejohn.com> wrote: <snip>
boost::defer would offer a way of posting the work unit to a Defer Point object that would call the unit of work in whatever is the appropriate thread. The Defer Point acts as a queue for scheduled work items
What you describe is similar to functionality provided by my proposed asio library. In particular see the asio::demuxer and asio::locking_dispatcher classes, which implement the Dispatcher concept (see http://asio.sourceforge.net/asio-0.3.5/doc/reference/index.html). For example, given an object d of a class that implements the Dispatcher concept, you can: 1) Request immediate execution of a function object. The function object will be called immediately provided the dispatcher's preconditions(**) for immediate execution are met, otherwise execution is deferred: d.dispatch(some_function_object); 2) Request deferred execution of a function object: d.post(some_function_object); 3) Create a new function object that will automatically dispatch the original function object: new_function_object = d.wrap(some_function_object); ** The preconditions are up to the specific Dispatcher implementation. In the case of the asio::demuxer class, it's that the current thread is currently invoking demuxer::run().
1. One single thread defer point, reused throughout a program -> cooperative multi-tasking
This sort of "cooperative multi-tasking" design is common to apps that use asio to perform asynchronous I/O and other tasks. With careful design (and judicious use of asio::locking_dispatcher), it also works when the demuxer uses a pool of threads.
I've found these threading concepts to be useful in large-scale projects where multiple libraries want to do callbacks into some application code. Defer Points allow you to parameterise those libraries in such a way as to play nicely with eachother - deferring their callback strategy to a style defined by the programmer integrating the libraries into the final app.
Its also handy where multiple entities in a program need to call into each other, potentially recursively (A calls B calls A calls B) Better to break this recursion with queues of work items.
Yep, I also find this approach particularly useful for the same reasons as you. Cheers, Chris