Re: [boost] [next gen future-promise] What to callthemonadicreturntype?

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 
be duplicated/manyplicated.

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