Re: [boost] Futures - Reviews Needed (January 5, 2009)

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.