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. Braddock Gaskill Dockside Vision Inc