Re: [boost] Re view Request: future library (N2561/Williams version)

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-23 05:45:23

Frank Mori Hess wrote:
> 
> In case you're interested, I've just implemented future_barrier and 
> future_select (changed name from future_switch) free functions in libpoet 
> cvs:
> 
> http://www.comedi.org/cgi-bin/viewvc.cgi/libpoet/poet/future_waits.hpp?view=markup
> 
> I didn't do any clever under-the-hood optimizations, only provided
> overloads 
> that accept 2 to 10 future<T> arguments, plus one that accepts first/last 
> iterators to a container of futures.
> 

Interesting! Do you use these within poet anywhere or is it for poet users
only?

I think it would be good to add some functionality though. For simplicity,
let's only talk about the select case. This is what I propose:

1. Clients will probably be interested in which of the child futures fired.
The interface should support this.

2. Upon notification from a child, I'd want to be able to check a condition
and then either
   a - become ready
   b - prune the "consumed" child future and go back to sleep
2.1 This condition checking should probably be done by the first thread
which is waiting for the future - it belongs to the future-listening
threads, not the promise-fulfilling one. If nobody is waiting for the future
we should save this evalution and let it be performed lazily as soon as
someone queries the future or waits for it.
2.2 This evaluation is not just a predicate which can make the future ready.
It can also be actual calculations. These would be performed from within
future::wait(), get() and is_ready().
2.3 We probably need to supply a default value if all children have been
consumed

3. We probably want to support composite futures from different types. If we
want to support 1 or 2 we want to get access to the typed value of the ready
future. In practice, this probably means the evaluation function should be
added at the same time as the child future to ensure type safety. See the
interface example below.

A simplified example of what an interface which supports 1, 2 and 3 might
look like is:  

template<class ReturnType, class Arg1Type, class Arg2Type>
future<ReturnType> future_select(future<Arg1Type> f1,
function<optional<ReturnType>(Arg1Type)> e1,
                                              future<Arg2Type> f2,
function<optional<ReturnType>(Arg2Type)> e2,
                                              ReturnType default_value);

I'm not entirely satisfied with this though. 

In the end, I want users to be able to easily "lift" ordinary functions to
futures:
int foo_func(int, double, bool) => future<int> foo_func(future<int>,
future<double>, future<bool>)

I have also been thinking about we could move part of this composed waiting
in to a conditon_variable_node class to separate concerns. 

Johan
-- 
View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-tp16600402p17422354.html
Sent from the Boost - Dev mailing list archive at Nabble.com.