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-19 03:18:42

#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 [comment:3 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.

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