Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st

Subject: Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
From: Nat Goodspeed (nat_at_[hidden])
Date: 2009-10-20 15:47:09

[Sorry, I know I'm replying to a very old post, but this IS continuing 
the same exchange.]

Frank Mori Hess wrote:
> 
> On Wednesday 18 February 2009, Nat Goodspeed wrote:
>>

[snip - talking about boost::signals2::signal::connect() accepting a 
boost::bind expression containing a boost::shared_ptr]

>> the
>> shared_ptr copy stored in the boost::bind() result makes the referenced
>> object effectively immortal.
>>
>> To my surprise, I find that it's not destroyed even when I explicitly
>> disconnect the resulting connection.

> It will get destroyed eventually.  The signal cleans up its slot list little 
> by little during connect/invoke.  It doesn't immediately remove disconnected 
> slots from the slot list since other threads might be using the same slot 
> list concurrently.  It might be possible to make it immediately reset the 
> shared_ptr owning the slot though, leaving an empty shared_ptr in the slot 
> list, since that wouldn't invalidate any iterators.

Frank, has this logic changed at all since Boost 1.39? I've bumped into 
a situation where the lazy cleanup is causing a crash.

We've got a DLL containing a slot stored in a signal used by the main 
program. Before attempting to unload the DLL, we disconnect the slot -- 
but the signal retains a reference to memory invalidated by the 
departure of the DLL, resulting in badness.

Would updating to Boost 1.40 solve this problem? Or is there some 
explicit cleanup call we could/should make with a 1.39 
boost::signals2::signal? Or could you suggest how to patch the logic as 
you describe above?

Many thanks.