Boost logo

Boost :

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-03-07 02:50:49

Frank Mori Hess wrote:
> Sorry it took me so long to reply to this, I just noticed it. If
> some_func is
> in the process of running in another thread when you call disconnect(), it
> may still be running when disconnect() returns. disconnect() does not
> block
> waiting for any slots to complete. In fact, no mutexes inside the signal
> are
> held while a slot is executing, to avoid deadlock issues.

This means disconnect semantics are different for threaded and non-threaded
policies. How will you make this clear to users? A typical signals n' slots
use case is - at least for me:

signal<void()> sig;

class Foo{
  Foo() {
    con = sig.connect(bind(&Foo::some_func, this));

  scoped_connection con;

  void some_func() {}

If the signal was thread-safe this could very well crash the user

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