On 3/12/07, Braddock Gaskill <braddock@braddock.com> wrote:
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 active_function.
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.
Take a look at my coroutine library, developed during the last SoC: http://www.crystalclearsoftware.com/soc/coroutine/index.html The reference documentation is still missing, but I hope to have it finished very soon now (TM) and submit it for review. And yes, it has futures. Even if the current implementation can only be used to wait for asynchronous asio calls, supporting asynchronous procedures in other threads should be fairly easy. gpd