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

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;

  scoped_lock l(mutex1);

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

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.


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at