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

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-14 19:21:44

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

Johan
-- 
View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-tp16600402p17243011.html
Sent from the Boost - Dev mailing list archive at Nabble.com.