Boost C++ Libraries: Ticket #9103: execution of slots on deletion of signals

component changed; owner set

anonymous — Mon, 16 Sep 2013 15:25:58 GMT

owner set to Frank Mori Hess
component None → signals2

Frank Mori Hess — Mon, 16 Sep 2013 19:57:38 GMT

Replying to 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:

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.
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.
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.

wim@… — Wed, 18 Sep 2013 16:40:21 GMT

The question to answer is: how do you want to support signal/slot connections where slots may modify the data structure in such a way that the signalling object is deleted.

In Wt (www.webtoolkit.eu) we regularly encounter these 'delete this' cases (directly or indirectly), e.g. in situations where the 'Ok' button of a dialog or a widget causes the dialog or widget to be closed or removed. With signals2, the behaviour changed when multiple slots are connected to such a self terminating signal, which lead to a bug report. In this report, a signal from a single-shot timer was connected to a method that executed the 'delete this', in addition to multiple connections that are handled by other objects that are not affected by this deletion. That's just another example of a self-destructing signal.

I'd prefer compatibility with boost.signals is implemented. As you indicate, it makes the signals disconnect behaviour more consistent with the connect case, and it would also make signals2 more compatible with the original signals library. Projects moving from signals to signals2 (because of the official deprecation of the original signals library) will run in this subtle, difficult to debug use case. As I understand it, the boost.signals behaviour is slightly different from what you describe in (3): disconnected slots will not be executed when disconnects occur during the calling sequence. I have no idea what happens with blocked slots.

Or can you suggest a work-around (copying the signal to the stack before invoking it?) that would have compatible behaviour?

Frank Mori Hess — Thu, 19 Sep 2013 03:18:42 GMT

Replying to wim@…:

In Wt (www.webtoolkit.eu) we regularly encounter these 'delete this' cases (directly or indirectly), e.g. in situations where the 'Ok' button of a dialog or a widget causes the dialog or widget to be closed or removed. With signals2, the behaviour changed when multiple slots are connected to such a self terminating signal, which lead to a bug report. In this report, a signal from a single-shot timer was connected to a method that executed the 'delete this', in addition to multiple connections that are handled by other objects that are not affected by this deletion. That's just another example of a self-destructing signal.

Thanks for clarifying your use case. I see how the disconnect in the signal destructor is annoying for you.

As I understand it, the boost.signals behaviour is slightly different from what you describe in (3): disconnected slots will not be executed when disconnects occur during the calling sequence. I have no idea what happens with blocked slots.

Thanks for pointing that out. I'll play around with the original Signals library when I get the time, to refresh my memory of its behavior. Maybe the most compatible and easiest change will turn out to be to just drop the call to disconnect_all_slots in the Signals2 signal destructor.

Or can you suggest a work-around (copying the signal to the stack before invoking it?) that would have compatible behaviour?

signals are non-copyable so you can't do that. If your signal was owned by shared_ptr, you could prevent the signal's destruction during invocation by copying an owning shared_ptr to the stack.

Frank Mori Hess — Sun, 22 Sep 2013 21:21:35 GMT

(In [85836]) Don't force disconnection of all slots in signal destructor. Refs #9103

status, milestone changed

Frank Mori Hess — Sun, 22 Sep 2013 21:23:57 GMT

status new → assigned
milestone To Be Determined → Boost 1.56.0

Too late to merge into release for 1.55, change will be in 1.56.

status changed; resolution set

Frank Mori Hess — Tue, 12 Nov 2013 03:02:09 GMT

status assigned → closed
resolution → fixed

(In [86632]) Merge from trunk. Fixes #9103