Re: [boost] [future] Early draft of wait for multiple futures interface

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-30 10:36:52

Peter Dimov-5 wrote:
> 
>> is_ready doesn't trigger the callback, so this won't work.
>>
>> OTOH, I think is_ready should trigger the callback, even for the "run 
>> extra
>> work in wait()" thread pool use case.
> 
> ready() should trigger a separate "ready callback", since its semantics
> are 
> not the same.
> 
> (f1 || f2).ready :- f1.ready || f2.ready
> (f1 || f2).wait :- wait_for_any(f1, f2)
> 

No, (f1 || f2).ready != f1.ready || f2.ready. 
f1 can be ready and false, in which case we need to wait for f2 to become
ready until the composite future is ready.

> Java futures don't have this callback proliferation problem because they
> are 
> abstract.
> 
> class future
> {
> public:
>     virtual void wait() = 0;
>     virtual bool ready() = 0;
> };
> 

There are other ways of solving this too, without exposing callbacks. 

> but we'd rather like to pass and return futures by value. :-) 
> 

What do you mean?

Johan
-- 
View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-interface-tp17242880p17560501.html
Sent from the Boost - Dev mailing list archive at Nabble.com.