Re: [boost] [futures] boost::futures

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-14 15:47:51

On Wed, 14 Mar 2007 17:47:09 +0100, Giovanni Piero Deretta wrote:
> Instead of going with generalized future composition, I've tried the route of
> 'wait_all(<future-list>) ' and 'wait_any(<future-tuple>)'

This is exactly what I personally would like to see.  I don't relish the
thought of digging out a return type or exception from a future<variant<float,
string, tuple<int, double, bool> > >.  I would just want something that wakes
me up when dinner is ready and let me figure out which of my futures are valid
or have failed, if I even care.

wait(f1 || (f2 && f3));
might be nice syntax, does actually add functionality, and is simple enough as well.

IMHO, all of this fancy blocking stuff should really be part of a larger event
framework anyway.  I'd love to throw a pair of futures together with a
non-blocking file read and a listening UDP socket, and have the wait() yeild my
thread to another task while I'm dreaming.  

But this is a far bigger problem than the future concept.  add_callback() is my
answer to disentangling future<T> from the general blocking problem.

>> I personally don't like the idea of having the future convert implicitely to
>> its value type at all.

Nor do I.  Herb Sutter has a good slide in his Concur presentation against it
as well.

> I agree. What about an optional<T> like interface for future<T>?
>   future<some_type1> a = async_op1(...);
>   some_type1 xa = *a; //may block if not yet ready

Personally, I just prefer no non-sense 'get()'.  But I'm willing to
implement whatever the general consensus is, and/or whatever gets past the
C++ language committees.

Braddock Gaskill
Dockside Vision Inc