[Development] Allowing event delivery prior to and after QCoreApplication
Thiago Macieira
thiago.macieira at intel.com
Tue Apr 14 16:36:49 CEST 2015
On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote:
> Would it be feasible to make event loops started before and after
> QCoreApplication truly independent from notify() but all the others "join"
> in?
Not without race conditions.
if (self)
return self->notify(object, event);
// deliver directly
return doNotify(object, event);
What happens if the QCoreApplication gets deleted between the first and second
lines? In fact, what happens if it begins destruction? That's totally in the
land of undefined behaviour.
I'm not introducing the race condition, it already exists:
inline bool QCoreApplication::sendEvent(QObject *receiver, QEvent *event)
{ if (event) event->spont = false; return self ? self-
>notifyInternal(receiver, event) : false; }
I only three possible outcomes here:
1) ignore the problem and document it that Qt event delivery is unsafe if you
have any threads running by the time QCoreApplication gets deleted
2) fix it by not passing through notify() outside the main thread. That's the
solution I implemented in I27eaacb532114dd188c4ffff13d4ad2a4bb443e6.
3) introduce a global, recursive QReadWriteLock that prevents QCoreApplication
destruction from concluding. Note that it cannot prevent the destruction from
starting, so the virtual table may still change and we are still in undefined
behaviour by calling a virtual after the object began destructing.
I recommend against 1 and 3
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list