On 30 Aug 2015 10:04 pm, "Agustín K-ballo Bergé"
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 standard. 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