Boost logo

Boost :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-04-11 12:13:26

Hash: SHA1

On Friday 11 April 2008 10:36 am, Peter Dimov wrote:
> It seems to me that if you need to create futures on demand, then the
> non-automatic cancelation should not be used. If some future holder calls
> cancel, later futures created by this promise will not work. I can't think
> of a situation where this would be desirable.
> Storing a future in addition to the promise does disable the implicit
> cancelation - by design; presumably if you need the capability to create
> more futures at some later point, you don't want the task canceled in the
> meantime. And if you don't mind the task being canceled since you no longer
> need to create futures, you just reset() your local future copy.

Would support for releasing a future's reference count be acceptable in this
scheme? That is, something like

future<void> fire();
        future<void> forget = fire();
        forget.release(); // promise is not cancelled when forget destructs

Releasing a future would make the associated promise uncancelable, would this
be a problem?

Tangentially, would the addition of a weak_future make future reference
counting more palatable?

- --
Version: GnuPG v1.4.6 (GNU/Linux)


Boost list run by bdawes at, gregod at, cpdaniel at, john at