[Development] Allowing event delivery prior to and after QCoreApplication

[Simon Hausmann]

On Tuesday 14. April 2015 07.36.49 Thiago Macieira wrote:
> 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

I understand that you're not introducing a new race condition, but we also 
have to consider that option number 2 results in the removal of a feature that 
is documented and has been there for a long time and that works in the common 
case. The common case I'm thinking of is that an application starts up, after 
some time it starts one or multiple working threads, then those threads 
terminate and maybe at some point later the application also terminates.
That case works just fine and my concern is that there are people out there 
using this feature.


That said, I personally think the feature of having this ultra-central hook 
that is called from all (Qt) threads is a bad feature to have. If we were 
discussing the introduction of it, I would probably attempt to argue against 
it.

However now we are discussing the removal of it, and I think we need more 
insight on that before going ahead.


Simon