Re: [boost] Re view Request: future library (N2561/Williams version)

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-27 09:40:20

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 27 May 2008 05:46 am, Johan Torp wrote:
> Do you really need to hold the future's mutex while doing the evaluation?
> Can't other threads just see it as not_ready until the evaluation is
> complete and one of the future-listeners call future::set() or
> future::set_exception() on the composite future?

You're probably right, I shouldn't say things can't be done until I've tried 
to do them :)

> If you set up a composite future and
> then share it to other future-listening threads, you can state that this
> future can throw this and that or does xxx. The promise-fulfiller OTOH
> should be de-coupled from what it's listeners are doing.

That's a good point, if the only way to add callback code is in the factory 
functions for the composite futures, it means the callback code is only run 
by the newly created composite future (or possibly a copy of it), but doesn't 
effect the input futures or any other copies of the input futures which may 
already exist.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIPA9H5vihyNWuA4URArUEAJwI6tkpgEUVnedavsJ//CyFgvBdZgCeJk9A
bX/3oDCNumLAqJgZSxvcSow=
=Moh4
-----END PGP SIGNATURE-----