Boost logo

Boost :

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:
> 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.

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at