On 26 May 2015 1:44 pm, "Peter Dimov"
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): https://github.com/gpderetta/libtask/blob/master/event.hpp Generic then (also at the end of the file): https://github.com/gpderetta/libtask/blob/master/future.hpp
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: http://lists.boost.org/mailman/listinfo.cgi/boost