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