Re: [Boost-users] [signals] Automatic connection management and MT

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-02-05 17:28:57

On Monday 05 February 2007 12:49 pm, Timmo Stange wrote:
> Frank Mori Hess wrote:
> > There's also the matter of what happens in a combiner if a slot
> > it hasn't reached yet is  disconnected while it is running, which also
> > will affect EPG::signal since it allows disconnect to happen during
> > signal invocation, as long as the particular slot in question is not
> > running.  I was planning to make the slot iterator dereference
> > operation throw an exception if the slot has been disconnected.

> I'm not sure I understood this correctly. It should be ok for the client
> to disconnect slots that already have been called or will be called
> from an invocation context. That's what you have the ordering for. And
> it's no problem for the signal either.

I'm probably just exposing my ignorance of the boost.signals 
implementation.  Maybe what I'm worrying about can be hidden inside the 
slot iterator when I get to that.

I've been adapting the signals::track() stuff from mt_signal to 
thread_safe_signal, and as I was testing I've made an annoying discovery.  
I often like to set up connections in the constructor of an object which 
connect signals from member objects to slots which are member functions.  
However, it seems impossible to get a shared_ptr to "this" while inside 
the constructor that is useable for tracking.  Are there any possible 
work-arounds besides using a private constructor with a static factory 
function (a solution which doesn't extend well to derived classes), or 
doing the connection setup in a member function that has to be called 
separately after the object is constructed?

Is there some way to have signals::tracked initially hold a full 
shared_ptr, until it is known that the object has had a chance to have its 
ownership passed to an external shared_ptr?  Or maybe a version of 
shared_from_this() which returns a shared_ptr whose use_count is initially 
artificially inflated by one, until an external shared_ptr comes along and 
tries to increment the use count.

-- 
Frank