Re: [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-09-01 11:04:53

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.

>>>   A dismissible, efficiently implementable
>>>
>>> 'then' protocol could be the key for future composition across
> libraries. I
>>> would prefer if in this case the continuation were pointer sized to allow
>>> lock free implementations.
>>
>>
>> I don't think pointer sized continuations would buy you anything, you can
> attach multiple continuations to a single shared-state (via
> `shared_future`) so you will always end up needing memory allocation
> eventually. That doesn't stop you from attaching the pointer to the
> continuation decayed-copy in a lock free way.
>>
>
> Only if you use shared state. I'm looking at optimising unique futures. My
> shared future implementation currently is internally N unique futures plus
> a multiplexer.

You always have a shared state (the concept, in one form or the other), 
it is part of the specification of the semantics.

> Also for waits you can always allocate the waiter/signaler on the stack.
> The tricky part is handling the race between a dismissal and a signal.

This is exactly the trickiness I was referring to for `wait_for/until` 
vs `wait`.

> To implement the generic 'then' I do always heap allocate, but I put the
> callback inline with the returned future shared state. I use the pointer
> sized dismissible 'then' to chain the two shared states.

Nod, and after the allocation you can attach the pointer to the callback 
in a lock free way. You can further chain multiple continuations for a 
`shared_future` in a similar way.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com