signal garbage collection of slot objects

[fmh6jj@…]

Some people find the garbage collection scheme used by signals to destroy their disconnected slot surprising, in that slot objects inside the signal are not necessarily destroyed promptly upon their disconnection. An alternative scheme would be to reference count the use of each slot object and destroy it when it is disconnected and no longer needed by any ongoing signal invocation. Care would need to be taken to avoid a heavy performance impact (we probably wouldn't want to add an atomic reference count, but rather rely on the existing signal mutex for thread saftey).

[julien.puydt@…]

It's still the case with 1.55, and is annoying when one tries to reclaim memory as soon as possible and detect issues with memory management at fixed points.

Is there a workaround?

[dsandras@…]

We are really annoyed by this problem in the Ekiga project. What would you suggest ?

[fmh6jj@…]

I'll try to get this change done sometime in the next week

[dsandras@…]

Thanks !

What can we do to force the cleanup to happen until then?

Actually, when objects are destroyed when the process exits, we see all destructors are not called correctly because of this scheme.

[fmh6jj@…]

If you destroy a signal, all the slot objects it contains are also destroyed (unless it is concurrently being invoked when it is destructed, in which case the signal's internals are destructed when invocation completes).

[Frank Mori Hess]

Fixed on develop branch