Normally, disconnectNotify() is called at the end of QObject::disconnect
and all the locks have been dropped. That is not the case for the
QObject destructor, so we need to deal with the fact that it there may
be some locks held.
I didn't catch this issue during testing because it depends on the
pointer addresses of the object being destroyed and that of the
QDBusAbstractInterface sender object, as we use one global, non-
recursive mutex pool. For the same reason, this patch is not testable.
The fix is simple: we don't need to remove the relay rules immediately.
It's ok for them to happen later, since the worst case scenario is that
we'll receive a few more signals than we have objects to deliver them
to. If that happens, we'll do a little more work than we have to. But in
the normal case, the amount of work is the same and we get the benefit
of returning more quickly from the destructor. What's more, if the
QDBusAbstractInterface object also gets destroyed, the events are
deleted and QDBusConnectionPrivate will clean everything up.
Task-number: QTBUG-48410
Change-Id: I42e7ef1a481840699a8dffff1406b789ba5217b3
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
58d9b42c03