Boost logo

Boost :

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-09-01 08:35:30

On 30 Aug 2015 10:04 pm, "Agustín K-ballo Bergé" <kaballo86_at_[hidden]>
> On 8/30/2015 5:06 PM, Niall Douglas wrote:
>> 7. future.wait() very rarely blocks in your use scenario i.e. most if
>> not nearly all the time the future is ready. If you are blocking, the
>> cost of any thread sleep will always dwarf the cost of any future.
> `future::wait` should not be a concern, you just spawn a
`condition_variable` and attach a fake continuation to the future that will
wake it up. The cv will be stored in the thread stack, which is guaranteed
to stay around since we will be sleeping. This allows the fake continuation
to simply be `reference_wrapper`, for which you only need `sizeof(void*)`
embedded storage. Since the (unique) future cannot be used concurrently
with `wait`, there can only ever be at most one fake continuation.

This is unfortunately not true. Std::future::wait is const, so, without an
explicit prohibition, multiple threads can call it as long as no other non
const function is concurrently called. This is possibly a defect of the

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. 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.

-- gpd

Boost list run by bdawes at, gregod at, cpdaniel at, john at