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

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-25 12:05:57

Frank Mori Hess wrote:
> 
> 1) In order to wait on an arbitrary number of futures, determined at
> runtime, 
> we need some kind of container.  
> 

Yes, but it needn't be exposed to users. As you suggested, it can be built
up with free functions or expressive templates, similar to Gaskill's comb.
This is a detail though, I don't want to focus on it now.

Frank Mori Hess wrote:
> 
> 2) Since containers are homogeneous, that means some kind of type erasure 
> (future<void>).
> 

Yes, type erasure will be needed. I hope we can rely on boost.function for
that, similar to the predicate version of condition_variable::wait().

Frank Mori Hess wrote:
> 
> 3) When a future becomes ready, we will often want to dispatch it somehow 
> which might mean getting its value, or at least identifying the input
> future 
> which became ready.  That could mean doing some kind of type unerasure, or 
> doing an inefficient loop over all the original input futures until you
> find 
> the completed one.  Your solution is to bind the dispatcher function to
> the 
> future before it is type erased.  For thread-safety, you want to run the 
> dispatcher function in one of the waiting threads, right after the future 
> becomes ready.
> 

Thread safety is not my primary concern. The "predicate" code might throw an
exception and the promise-fullfilling thread can't be expected to catch it.
That would couple the promise-fulfiller and the future-listeners in an
awkward way. 

An alternative might be to catch the exceptions and set them on the
composite future. Thinking of it, this would be the expected behaviour,
wouldn't it?

Frank Mori Hess wrote:
> 
> There will be deadlock hazards running the user's dispatcher function
> while 
> holding the future's associated mutex.
> 

Good point. I hope we don't need to hold any mutex while evaluating the
predicate.

Frank Mori Hess wrote:
> 
> Also, it's possible multiple threads 
> will be waiting on the future, in which case how much thread-safety
> benefit 
> is there to running code in one of the waiting threads versus a callback
> run 
> in the promise 
> thread?
> 

The callback does not need to be thread safe unless it holds references to
some particular thread's data. Only one of the waiting threads will evaluate
it. Also, if there is only one "listening" thread it can safely reference
it's own data.

Frank Mori Hess wrote:
> 
> What if we allow a key value to be associated with each input future, then 
> return the key of the completed future?  Then it would be left to the user
> to 
> map the key back to whatever future they were originally interested in.
> 

This would mean a runtime mapping. This costs some but more importantly
could introduce bugs because of the added runtime insecurity.  I'm hoping we
can avoid it.

I'm doing a thesis related to C++0x and threading. Peter Dimov suggested I
could try and implement an event-like waiting primitive, similar to Windows'
WaitForMultipleObjects. If we had such a primitive, we might get better ways
to solve this problem. I think part of the reason this is so tricky is
because condition_variable's aren't meant to be used for multiple waiting.
Maybe Dimov or somebody else has sketches of such an interface. Maybe we
should solve this problem first. What do you think?

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