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

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

Frank Mori Hess wrote:
> 
>> > If we want to support dynamically adding futures to future_switch and
>> > maybe future_barrier a free function won't suffice.
>>
>> Yes, you're right.  Especially with future_switch there should be a way
>> to
>> wait on a group of futures whose number is only known at runtime.
> 
> Hmm, actually what I said is wrong.  As I believe has been pointed out
> before 
> by others on this list, you could build up a arbitrary size group of
> futures 
> to wait on at runtime by taking the return value from the free
> future_barrier 
> or future_switch function and passing it to another call.  So I'm still 
> partial to the free function approach.  It is similar to operator|| and 
> operator&& in Gaskill's library except not operators, no comb<T> class or 
> op() function, and overloaded to accept more than 2 arguments:
> 

It is possible, what I meant by "won't suffice" is that it will be very
innefficient. Imagine implementing or for 1000 futures. If you have
"collection" you can just add children and get a tree with depth 2 and where
the root node has 1000 childs. If you rely on free functions, say of arity
2, you get a tree depth of a 1000 and need 999 extra parent nodes which all
has one leaf node and one of the parent nodes as child.

Frank Mori Hess wrote:
> 
> future<void> future_barrier(const future<void> &a1, const future<void>& 
> a2, ... , const future<void> &aN);
> 
> future<void> future_switch(const future<void> &a1, const future<void>& 
> a2, ... , const future<void> &aN);
> 
> A naive implementation would probably be pretty inefficient when
> evaluating a 
> future that has been produced after passing through many 
> future_barrier/future_switch calls.  But I imagine some optimizations
> could 
> be found under the hood in the implementation to avoid unnecessarily long 
> chains of futures depending on each other.
> 

This would be nice and could potentially solve the inefficiency problem. You
are allowed to wait for any node in a tree. The main difficulty is figuring
out which nodes only exists in the tree and which who are visible to the
outside world. The nodes who only exist in the tree can be re-arranged into
a compact tree. Maybe we can use unique_future to guarantee this. I.e. the
combination functions always return unique_futures and if we get these as
in-parameters, we can safely re-arrenge the tree.

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