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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:14 UTC