Boost logo

Boost :

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-03-13 06:12:05


On 3/12/07, Braddock Gaskill <braddock_at_[hidden]> wrote:
> 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.
>

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk