Re: [boost] boost::defer - generalised execution deferral

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-11-26 03:17:34

Hi Simon,

--- simon meiklejohn <simon_at_[hidden]> 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