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