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