Boost logo

Boost :

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

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

- --
Version: GnuPG v1.4.6 (GNU/Linux)


Boost list run by bdawes at, gregod at, cpdaniel at, john at