Boost logo

Boost :

Subject: Re: [boost] [next gen future-promise] What tocallthemonadicreturntype?
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-05-26 09:15:10

On 26 May 2015 1:44 pm, "Peter Dimov" <lists_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
>> > auto f = when_any( f1, f2, f3, f4 ); // 2^4 options
>> The algorithm can be generic of course.
> Can it be generic? Do you have a generic implementation of when_any?

You do need to standardise a generic asynchronous wait protocol of course.

I have a generic 'wait_any' (it blocks, it doesn't return a future), and a
somewhat generic 'then' (the returned future is not generic, but can wait
on multiple waitables). I do not have a generic when_any, but should be a
matter of putting those two together.

Wait_any/all (toward the end of the file):

Generic then (also at the end of the file):

>> You'll have the same problem if you want to mix different futures from
separate libraries.
> Yes, I know. Hence my preference for a single std::future that is _the_
future type.

Good luck with that :)

>> You are right of course. The readiness notification is orthogonal, but
in a shared future you need a mutex to synchronise the various consumers
access to the shared state, so a condition variable becomes the obvious
choice, while you can be more creative with plain futures.
> No, in fact I do not need a mutex to synchronize consumers, as far I can
see. Where would I need it? Consumers don't interfere with one another.

You need to protect concurrent calls to then and also to wait if you allow
consumers to provide their own wait object (which you need at least for
wait any). Possibly also concurrent when_any/all, but i haven't tried
implementing that. You might as well use it to protect the refcount.

I concede that it might not be required with the current limited
std::future interface.
> Unsubscribe & other changes:

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