Re: [boost] [signals/threadsafe version] Atomic disconnects

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
application.
-- 
View this message in context: http://www.nabble.com/-signals-threadsafe-version--Atomic-disconnects-tp15412841p15891072.html
Sent from the Boost - Dev mailing list archive at Nabble.com.