Re: [boost] Review Request: future library (Gaskill version)

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

-----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-----