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