Boost logo

Boost :

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.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk