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

Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2009-01-19 16:07:58

----- Original Message ----- 
From: "Frank Mori Hess" <fmhess_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, January 19, 2009 9:03 PM
Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)
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.

Hi, 
I have 3 questions, 
Can this poet::future_combining_barrier (function?) , poet::future_selector be implemented with the current proposals? 
If yes there is no issue. If no, what is missing in the current interface to implement them?

I see on the web that libPoet have its onw mutexes, exception_ptr, futures, scheduler and much more ...
Is libPoet a candidate to be included in Boost or a stand alone library? 
Do you plan to propose libPoet or part of it to Boost?

What about doing a review? It is not too late.

Best,
Vicente