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

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-16 11:05:55

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

On Friday 16 May 2008 10:15 am, Frank Mori Hess wrote:
> On Friday 16 May 2008 05:23 am, Johan Torp wrote:
> > Frank Mori Hess wrote:
> > > 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>&
> > > a2, ... , const future<void> &aN);
> >
> > If we want to support dynamically adding futures to future_switch and
> > maybe future_barrier a free function won't suffice.
>
> Yes, you're right.  Especially with future_switch there should be a way to
> wait on a group of futures whose number is only known at runtime.

Hmm, actually what I said is wrong.  As I believe has been pointed out before 
by others on this list, you could build up a arbitrary size group of futures 
to wait on at runtime by taking the return value from the free future_barrier 
or future_switch function and passing it to another call.  So I'm still 
partial to the free function approach.  It is similar to operator|| and 
operator&& in Gaskill's library except not operators, no comb<T> class or 
op() function, and overloaded to accept more than 2 arguments:

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

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

A naive implementation would probably be pretty inefficient when evaluating a 
future that has been produced after passing through many 
future_barrier/future_switch calls.  But I imagine some optimizations could 
be found under the hood in the implementation to avoid unnecessarily long 
chains of futures depending on each other.

These prototypes assume the future lib supports conversion of any future<T> 
type to future<void>.

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

iD8DBQFILaLU5vihyNWuA4URAuuSAJ9/dlFhPWn/USbuVQCcgoKZBJVDJACfRfEH
cOeNVQBDhQy/Ifd8Bkj/Slk=
=vG5O
-----END PGP SIGNATURE-----