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, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk