From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-12 17:12:17
On Tue, 13 Mar 2007 00:30:39 +1100, Christopher Kohlhoff wrote:
> various futures proposals that are around, I prefer to keep the producer
> and consumer interfaces separate. Hence I have promise<T> (producer
> interface) and future<T> (consumer interface) -- these names are
Okay, this got me thinking.
A weakness in the future<> concept, as I understand it, is that if a future is
never set(), then the invoking thread can hang waiting for it. Not very RAII.
The situation is much improved if future<T> and promise<T> are split, and
promise<T> is reference counted. If the last promise<T> for a particular
future<T> goes out of scope, than any thread waiting on the matching
future<T> would be failed with a promise_broken exception or somesuch.
Is this already part of the promise<T> concept?
Braddock Gaskill
Dockside Vision Inc