|
Boost : |
Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: AgustÃn K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-09-01 12:44:31
On 9/1/2015 1:23 PM, Giovanni Piero Deretta wrote:
> On 1 Sep 2015 4:06 pm, "AgustÃn K-ballo Bergé" <kaballo86_at_[hidden]>
> wrote:
>>
>> On 9/1/2015 11:43 AM, Giovanni Piero Deretta wrote:
>>>
>>> On 1 Sep 2015 2:15 pm, "AgustÃn K-ballo Bergé" <kaballo86_at_[hidden]>
>>> wrote:
>>>>
>>>>
>>>> On 9/1/2015 9:35 AM, Giovanni Piero Deretta wrote:
>>>>>
>>>>>
>>>>> On 30 Aug 2015 10:04 pm, "AgustÃn K-ballo Bergé" <kaballo86_at_[hidden]
>>
>>>>> wrote:
>>>>
>>>>
>>>>>> The situation gets trickier for `wait_for/until`, where you need to
>>>
>>> remove
>>>>>>
>>>>>> the fake continuation on a timeout without racing.
>>>>>>
>>>>>
>>>>> Also needed to implement wait any.
>>>>
>>>>
>>>>
>>>> Once `wait` returns the shared-state is ready. You don't even need to
>>>
>>> remove the fake continuation pointer, it will never be looked up again.
>>>
>>> You do if you want to implement a wait_any interface that blocks until
> the
>>> first of a number of futures is ready. In that case you must be able to
>>> reissue another wait at a later time. Think 'select'.
>>
>>
>> I did not understood what you meant by "wait any" the first time around.
> I do now, but I still don't see why would you ever want to wait on an
> already ready future. If you do, it would just return immediately; it
> should not even touch callbacks, continuations, condition variables, etc.
>>
>
> Uh? You do not wait on a ready future. You might wait for one of the other
> futures that are not ready.
I think I might understand now. You mean that `wait_any` is just as
tricky as `wait_for/until`, given that you might have to as you say
"unwait", to which I agree.
I misunderstood your original message and brought plain `wait` into the
picture.
Regards,
-- AgustÃn K-ballo Bergé.- http://talesofcpp.fusionfenix.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk