-----BEGIN PGP SIGNED MESSAGE----- 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? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH/44n5vihyNWuA4URAlNeAKCTcBdPz6E1EHb8NvOdQ8tHfolVcACePJ/t npAO6T8CpEfjrLdADCrenwc= =UQK4 -----END PGP SIGNATURE-----