Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
[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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 October 2009, Nat Goodspeed wrote:
Would updating to Boost 1.40 solve this problem?
No
Or is there some explicit cleanup call we could/should make with a 1.39 boost::signals2::signal?
No. Even if there was, a signal invocation concurrent with the disconnect could keep the slot alive. So there would also need to to be a method which blocks until all currently in progress signal invocations complete (which might be useful to have anyways). Can you use a shared_ptr with a custom deleter to unload your dll an ensure it is not unloaded while it is still referenced? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkreHXwACgkQ5vihyNWuA4XiiQCghJPTWAZqGzRiCB45HFiN6DhC LWUAoNt8KPL+5XRpxlqs6MUlBlVebeu+ =QjUc -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
there would also need to to be a method which blocks until all currently in progress signal invocations complete (which might be useful to have anyways).
Does that mean you're musing about a possible implementation?
Can you use a shared_ptr with a custom deleter to unload your dll an ensure it is not unloaded while it is still referenced?
I'm not sure I understand, but let me answer as if I do. The shared_ptr bound into the boost::bind() object stored in the signal's slot is just an ordinary shared_ptr to a heap object. It doesn't know it comes from a DLL, nor am I especially keen to tell it. I think the specific trouble is that my object's destructor is inlined in the DLL code.
I'm not sure I understand, but let me answer as if I do. The shared_ptr bound into the boost::bind() object stored in the signal's slot is just an ordinary shared_ptr to a heap object. It doesn't know it comes from a DLL, nor am I especially keen to tell it.
I guess he meant something like this:
// windows-specific:
boost::shared_ptr
Igor R wrote:
I guess he meant something like this:
// windows-specific: boost::shared_ptr
ptr(LoadLibrary("mylib.dll"), &FreeLibrary); // now you can bind "ptr" to the slots or anything that needs maylib.dll to be alive.
Oh -- so instead of using that shared_ptr for my real function, you're saying I could bind it as an ignored argument to a no-op function. That's true, and I thank you both for the suggested workaround. I remain hopeful that Frank might introduce a better solution before long. :-)
On Wednesday 21 October 2009, Nat Goodspeed wrote:
Igor R wrote:
I guess he meant something like this:
// windows-specific: boost::shared_ptr
ptr(LoadLibrary("mylib.dll"), &FreeLibrary); // now you can bind "ptr" to the slots or anything that needs maylib.dll to be alive. Oh -- so instead of using that shared_ptr for my real function, you're saying I could bind it as an ignored argument to a no-op function.
That's true, and I thank you both for the suggested workaround. I remain hopeful that Frank might introduce a better solution before long. :-)
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.
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.
participants (4)
-
Frank Mori Hess -
Frank Mori Hess -
Igor R -
Nat Goodspeed