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

1 Sep 2015

      On 1 Sep 2015 4:06 pm, "Agustín K-ballo Bergé" 
wrote:
...
On 9/1/2015 11:43 AM, Giovanni Piero Deretta wrote:
...
On 1 Sep 2015 2:15 pm, "Agustín K-ballo Bergé" 
wrote:
...
On 9/1/2015 9:35 AM, Giovanni Piero Deretta wrote:
...
On 30 Aug 2015 10:04 pm, "Agustín K-ballo Bergé" 
...
...
...
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.
...
...
Only if you use shared state. I'm looking at optimising unique futures.
My
...
shared future implementation currently is internally N unique futures
Uh? You do not wait on a ready future. You might wait for one of the other
futures that are not ready.

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.
Sorry, sloppy writing on my part. I meant shared_future, not shared state.
Unique futures also have shared state of course.
...
...
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.
...
Yes, that work perfectly if you never 'unwait'. Timed waits and wait_any
make things a lot more complex.  I do not think is worth keeping this case
lock free; I'm instead thinking of borrowing one bit from the chain head
pointer as a spinlock to guarantee mutual exclusion for shared removals. I
have yet to try to implement this though.

-- gpd