From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-04-11 12:13:26
-----BEGIN PGP SIGNED MESSAGE-----
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> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk