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

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-15 09:04:11

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

On Wednesday 14 May 2008 19:21 pm, Johan Torp wrote:
> Frank Mori Hess wrote:
> > 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.
>
> If you have the time, please look at my proposed solution at
> http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-int
>erface-to17242880.html. I think it solves both your problems without moving
> "user code execution" from future-blocking threads to promise-fulfilling
> ones. I'm very interested in seeing if it works well with scheduling and I
> think your input would be very valuable.

Ah, yes it seems like some kind of composable future_switch and future_barrier 
could work quite well for my use case.  Do they actually need to be classes 
though?  What if they were just free functions for example

future<void> future_barrier(const future<void> &a1, const future<void> 
7a2, ... , const future<void> &aN);

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

iD8DBQFILDTO5vihyNWuA4URAsOZAJ9YWXWRMuxZ5mPE34mkEGyUByHnKgCgpvCl
rIObEXk3c7/Izc3gje0s9ig=
=t+B+
-----END PGP SIGNATURE-----