Re: [boost] active objects implementation request for comments

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:
> http://www.comedi.org/projects/libpoet/index.html

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