Date: 2008-03-12 11:19:32
Date: 2008-03-12 11:19:32 EDT (Wed, 12 Mar 2008)
New Revision: 43574
Added a mention that slots may still be running after disconnect returns.
Text files modified:
sandbox/thread_safe_signals/libs/thread_safe_signals/doc/tutorial.xml | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
--- sandbox/thread_safe_signals/libs/thread_safe_signals/doc/tutorial.xml (original)
+++ sandbox/thread_safe_signals/libs/thread_safe_signals/doc/tutorial.xml 2008-03-12 11:19:32 EDT (Wed, 12 Mar 2008)
@@ -910,6 +910,14 @@
not change in the recursive case, except that the slot calling
sequence includes slot calls for all nested invocations of the
+ Note, even after a connection is disconnected, its's associated slot
+ may still be in the process of executing. In other words, disconnection
+ does not block waiting for the connection's associated slot to complete execution.
+ This situation may occur in a multi-threaded environment if the
+ disconnection occurs concurrently with signal invocation,
+ or in a single-threaded environment if a slot disconnects itself.
<section><title>Passing slots (Intermediate)</title>
@@ -1147,7 +1155,6 @@
However, if you use the <classname>boost::signalslib::multi_threaded</classname> class as
the ThreadingModel template parameter for your signals, you will have to link to the
Boost.threads library, libboost_thread.
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk