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

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-14 15:40:00

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

On Wednesday 14 May 2008 08:57 am, Johan Torp wrote:
> Anthony Williams-3 wrote:
> > Alternatively, you could do it with a
> > completion-callback, but I'm not entirely comfortable with that.
>
> I'm not comfortable with this either, for the reasons I expressed in my
> response to Gaskill's propsal.
>
> This issue is my biggest concern with the future proposal. The alternatives
> I've seen so far:
>
> 1. Change/alter condition variables
> 2. Add future-complete callback (Gaskill's proposal)
> 3. Implement wait_for_many with a thread per future
> 4. Implement wait_for_many with periodic polling with timed_waits
> 5. Introduce new wait_for_many mechanism (public class or implementation
> details)
> 6. Don't ever support waiting on multiple futures
> 7. Don't support it until next version, but make sure we don't need to
> alter future semantics/interface when adding it.
>
> Alternative 7 blocks the possibility to write some exciting libraries on
> top of futures until a new future version is available.

In my libpoet scheduler code I described in an earlier post today, I currently 
use the a future-complete callback (signals/slots more specifically).  
Although I could make my scheduler work with wait_for_many support instead, 
it would be more cumbersome and less efficient.  

First, with signals/slots I can avoid having to make the scheduler thread wake 
up every time any input future of any method request in the scheduler queue 
becomes ready.  Instead the individual method requests can observe their 
inputs, and only generate invoke a signal in turn when all of their futures 
are ready.  Then the scheduler only has to observe the method requests and 
doesn't have to wake up (possibly spuriously) and check every method request 
in its queue every time a single input future becomes ready.

Second, if all I can do is wait for multiple futures, then the scheduler has 
to additionally maintain and keep updated a separate container with all the 
input futures of the method requests currently queued.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIK0AR5vihyNWuA4URAk/8AJ9P/AMkQhvs6bcOTxlNy3ZdQ3ddygCgyt4o
qeFQZocP8r4yd7G+sBIt310=
=lkFA
-----END PGP SIGNATURE-----