Subject: Re: [boost] [next gen future-promise] What to callthemonadicreturntype?
From: Peter Dimov (lists_at_[hidden])
Date: 2015-05-26 06:47:57
Giovanni Piero Deretta wrote:
> On 26 May 2015 12:59 am, "Peter Dimov" <lists_at_[hidden]> wrote:
> > This non-allocating implementation is an interesting argument in favor
> > of the current "unique future", which I've long disliked. I prefer
> > futures to be shared_futures.
> Interesting, why do you dislike the unique future design?
I dislike the unique/shared future split, which requires all algorithms to
auto f = when_any( f1, f2, f3, f4 ); // 2^4 options
I prefer a single future<T> type, and I want this single type to be shared
because I want the above when_any to not std::move my futures, leaving me
with empty shells.
> A shared future pretty much requires holding a shared pointer and needs
> heavy weight synchronisation ( a muted+condvar or equivalent). On the
> other hand a unique future need no internal mutual exclusion and the only
> synchronisation is needed for the handoff between producer and consumer;
> the reference count is implicit (just have the consumer always deallocate
> the object). The implementation can be significantly more light weight.
I already acknowledged that these implementations are an argument in favor
of unique future.
But I don't think I agree with what you're saying. I don't see how
mutex+condvar is required by shared future but not by unique future (how do
you implement wait() is not related to sharedness), neither do I see how
unique futures require no synchronization (they obviously do in Niall's
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk