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-22 10:56:20

Frank Mori Hess wrote:

> It seems to me reference-counting usage of the dll and unloading it only 
> when the reference count reaches zero is a good solution.  It's the same 
> idea as using shared_ptr to destroy dynamically allocated objects rather 
> than passing out plain old pointers and manually calling delete.

That would make sense, yes.

Unfortunately, diving deeper into this, I find I'd misunderstood some of 
the details. The actual sequence appears to be more like this:

1. Before termination, code in the DLL calls disconnect() on its saved 
boost::signals2::connection. As we've seen, that doesn't actually clean 
up the stored slot object.

2. On program termination, the OS implicitly unloads the DLL prior to 
the executable image.

3. A static object in the main executable has a destructor that deletes 
the boost::signals2::signal object.

4. Destroying the (not yet cleaned) slot object destroys the underlying 
boost::function.

5. This calls boost::detail::function::basic_vtable1::clear(), which 
apparently tries to invoke code in the (now unloaded) DLL. As the 
original boost::bind() and connect() calls were made in DLL code, 
perhaps that method was inlined in that object file.

Much of the above happens implicitly, in particular the unloading of the 
DLL relative to the main executable.

What I'm trying to say is that I still believe there's a valid use case 
for forcing slot cleanup in some way.