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

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-30 12:13:31

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 30, 2008 5:56 PM
Subject: Re: [boost] [future] Early draft of wait for multiple 
futuresinterface

> Johan Torp <johan.torp_at_[hidden]> writes:
>
>> Anthony Williams-4 wrote:
>>>
>>>> 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.
>>>
>>> What does it mean for a shared_future<string> to be "ready and false"?
>>>
>>> I view "f1 || f2" as a short-hand for a call to wait_for_any(f1,f2)
>>> followed by either f1.get() or f2.get() depending on which was ready
>>> first.
>>>
>>
>> I was talking about future operators. That is the composite future we got
>> from f1 || f2, not selecting the first one which is ready. This should
>> become ready when it has an evaluated value of true or false.
>
> Are you envisaging "f1 || f2" as a short-hand for "f1.get() ||
> f2.get()" that may not need to wait for both? I see that as very
> limited utility, since it only works for future<R> where R can be used
> with ||.
>
> My "f1 || f2" is a future operator that returns a composite future. It
> is the future that is subject to ||, not the returned value.
>
>>>> There are other ways of solving this too, without exposing callbacks.
>>>
>>> Can you suggest some?
>>>
>>
>> I already have, all of my proposals has solved this without exposing any
>> external callbacks. I propose adding a parent-child relationship to 
>> futures
>> which is only exposed the wait for any/all mechanism. The
>> promise-fullfillers does not only notify their own condition, they 
>> traverse
>> their future's parents and notify them too.
>
> OK. This is similar to what I've done with detail::future_waiter. I
> could probably extend it to provide a full future that had the
> semantics of the future_or I posted earlier. I'll have a look next week.

Do you mean that  future_waiter will be public and not a implementation 
detail?

Vicente