Boost logo

Boost :

Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)
From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2009-01-19 15:03:23


On Monday 19 January 2009 13:19, Johan Torp wrote:
> Vicente Botet Escriba wrote:
> >> I would not be surprised if requiring a third thread for future
> >> composition
> >> would render it useless for many of Gaskill's use cases, libpoet and
> >> asio -
> >> which means most of the identified use cases. But I'm far from sure.
> >
> > Could you or someone develop these needs.
>
> The authors of asio, libpoet and Gaskill are best suited to answer if
> Anthony's proposal would be useful to them.

Unfortunately, I haven't had time to follow the future review threads in
detail, or any changes that may have been made to the submitted library
since I last looked at them many months ago. I can only summarize some
things about the future implementation in libpoet in the hope it will be
helpful in some way.

As far as composing futures, the poet::future_combining_barrier supports
obtaining a new future whose value is obtained by applying an
arbitrary "combiner" functor to the values from a group of input futures.
The combiner is always executed in a future-waiting thread, not the
promise-fulfilling thread, or a third thread. The implementation relies
on internal signals being emitted immediately when a promise is fulfilled,
as well as internal event queues associated with futures. I described it
a little in this post:

http://lists.boost.org/Archives/boost/2008/06/138422.php

With respect to an O(1) future wait_for_any, I added poet::future_selector,
which is like a future queue which reorders based on the order that the
futures pushed into the queue become ready.

I was able to use them to reimplement my schedulers for active objects,
without the scheduler using "future is ready" callbacks directly. To be
more clear about my use case: I have a thread which executes method
requests, and each method request has a group of futures associated with
it. The thread's scheduler has a queue of method requests and it selects
a method request to run when all the method request's futures are ready.




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