Boost logo

Boost :

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-12 18:42:46

On Fri, 09 Mar 2007 20:59:02 -0500, Frank Mori Hess wrote:

This is interesting. I've been working in a similar problem domain (dynamic
multi-threaded loading and processing with complex pipelines and a lot of io).

One problem with the heavy use of futures among asynchronous functions is that
when the function waits on a future, it ties up the whole thread - and there
may be a limited number. In my opinion, this is one of the more difficult
problems in doing this type of scheduled multi-threaded programming in C++.

In libpoet's case (and I've only just started looking at it), you might be able
to mitigate this somewhat if you check any future<T> arguments for an
active_function invocation within a default guard. ie, the default guard for
libpoet checks that all future<T> arguments are ready before running the

In general, what is REALLY needed is a form of continuation. Ideally, when
future<T>::get() blocks, control of the thread is yielded back to the
scheduler, which would continue the function once the future<T> is ready. I
noticed that the (very interesting) Intel threading library mentioned earlier
has a (very awkward) Continuation concept.

I don't think there is really any good way to do this though...perhaps a C++
coroutine implementation would do, but they still scare me.

Braddock Gaskill
Dockside Vision Inc

Boost list run by bdawes at, gregod at, cpdaniel at, john at