Re: [Boost-bugs] [Boost C++ Libraries] #9103: execution of slots on deletion of signals

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9103: execution of slots on deletion of signals
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-09-16 19:57:38

#9103: execution of slots on deletion of signals
-------------------------------+----------------------
  Reporter:  wim@…             |      Owner:  fmhess
      Type:  Bugs              |     Status:  new
 Milestone:  To Be Determined  |  Component:  signals2
   Version:  Boost 1.54.0      |   Severity:  Problem
Resolution:                    |   Keywords:
-------------------------------+----------------------

Comment (by fmhess):

 Replying to [ticket:9103 wim@…]:
 > These events can occur at any time without disrupting a signal's calling
 sequence. If a signal/slot connection is disconnected at any time during a
 signal's calling sequence, the calling sequence will still continue but
 will not invoke the disconnected slot. Additionally, a signal may be
 destroyed while it is in a calling sequence, and which case it will
 complete its slot call sequence but may not be accessed directly.
 >
 >
 > Since the slot is deleted in the calling sequence, I expect the calling
 sequence to continue, and 'hello' should be printed. This behaviour would
 be consistent with boost.signals (the deprecated version).
 >

 The docs are contradictory here.  The signal destructor is documented in
 the reference to disconnect all slots.  A disconnection in Signals2 takes
 effect for all slots which have not  yet begun to be executed (even if
 earlier slots in an invocation have already run when the disconnection
 happens).  This is a different behavior from the original Signals.

 So the options as I see them are:
 1. Delete the sentence describing a signal being destroyed in its calling
 sequence.  Technically, the slot call sequence does complete but since all
 the slots were disconnected by the signal destructor, no further slots are
 executed.  Also, there should be a paragraph added to the "Porting"
 section of the documentation noting the changed behavior of disconnect
 from the original Signals.
 2. Delete the sentence describing the signal destructor as disconnecting
 all connected slots.  Instead, the slots would be disconnected at some
 later point once all concurrent signal invocations are complete.  It would
 be possible for a series of overlapping signal invocations (via the weak
 references to the destroyed signal's implementation used by signals-used-
 as-slots) to prevent the slots from ever being disconnected.  The
 implementation also adds a slight overhead of once atomic increment and
 one decrement per signal invocation, for the reference counting to
 determine when the disconnects should be finally performed.
 3. Make Signals2 disconnection behave consistently with the original
 Signals.  Every signal invocation would have to make a local copy of the
 disconnected/blocked state for all the slots before executing any of them,
 and then ignore any changes that occur during invocation.  This may cause
 issues with existing Signals2 code, and it's not clear to me that this
 behavior is actually more desirable than the existing behavior.  Although,
 it would ease porting for those who haven't already.  It would also be
 make disconnects more symmetrical with connects, since newly connected
 slots are ignored by signals2 signal invocations if the invocation has
 already begun executing slots.

 I'm currently inclined to go with option 1.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/9103#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.