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-tp1541... Sent from the Boost - Dev mailing list archive at Nabble.com.