Re: [boost] Review Request: future library (Gaskill version)

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2008-04-10 22:11:21

On Thu, 10 Apr 2008 05:17:25 +0300, Peter Dimov wrote:
> I no longer like future<>::cancel. :-) 

future<T>::cancel is an impurity - I completely agree and devoted an
aside to that in my documentation.  But many will find it useful.

Future variables really should have nothing to do with task management. 
This is a major confusion which I've seen in prior future implementations
and standard proposals.  

Futures themselves should not be inherently tied to thread creation or
anything else...very limiting.  I provide a few hooks so that you can tie
futures to any scheduler, rpc scheme, or other asynchronous "backend".

> Have you considered the alternative 
> of automatically invoking the cancel handler when no futures remain? This 
> requires that a promise and a future be created at once:
> 
>     pair<promise,future> pc = create_channel();

The thought crossed my mind, but there are too many places in real-world
usage (I've had a lot now) where I find I want to get a future from a
promise.  I think it might be awkward to store both, and defeats the
intention of automatic cancelation.

> or, if empty futures are allowed:

I allow empty futures.  I tried without, but it got too awkward at times.

>     future f; // empty/detached
>     promise p(f); // attach p to f

If I can create a new promise from a future, then I can no longer detect
a "broken promise" exception (when the last promise associated with a
future goes out of scope for whatever reason, possibly leaving a future
forever waiting).

Thanks,
Braddock Gaskill