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-inte.... 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. Johan -- View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29... Sent from the Boost - Dev mailing list archive at Nabble.com.