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.
Dockside Vision Inc
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk