Boost logo

Boost :

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

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
>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);

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


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