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

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-26 16:13:59

Frank Mori Hess-2 wrote:
> 
> The thing is, this whole exercise started for me to see if it was possible 
> to get rid of the public signal/slots on futures and replace it with just 
> various waits on futures.  Once we start adding callback functions to the 
> future_select and future_barrier, which are executed on completion, it's 
> really a sign of failure to me.  I'd rather just leave the public slots on 
> futures as that is simpler, more powerful, and no less dangerous.
> 

I agree public slots are simpler and more powerful. IMO they are a lot more
dangerous though. Some examples:

If I connect a slot that might throw an exception, that exception will be
thrown from the promise-fullfilling thread's set()-call. This is totally
unexpected.

If a slot acquires a lock, it can lead to unexpected deadlocks if the
promise-fullfilling thread is holding an external lock while calling
future::set(). Assume you have two locks which you always should acquire in
some specified order to avoid dead-locks. Say you should acquire mutex1
before mutex2;

slot: 
  scoped_lock l(mutex1);

promise-fulfiller:
  scoped_lock l(mutex2);
  promise.set(100); // It is totally unexpected that this code will acquire
mutex1

other thread: 
  scoped_lock l(mutex1);
  scoped_lock l(mutex2);

I don't know how common this particular example would be but I'm guessing
there are lots of similar problems out there. Basically, you don't expect
future::set to run a lot of aribtrary code. And if you do, you have coupled
the future-listeners and future-fulfillers in a very implicit way.

If futures are internal to a library such as poet it is fine. But to expose
a generic future-object with such an interface is far from optimal, IMHO. 

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