[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