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-18 16:40:21

#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 wim@…):

 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?

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