[Development] Allowing event delivery prior to and after QCoreApplication

Simon Hausmann simon.hausmann at theqtcompany.com
Tue Apr 14 16:26:19 CEST 2015


On Monday 13. April 2015 21.12.58 Thiago Macieira wrote:
> On Monday 13 April 2015 13:23:29 Thiago Macieira wrote:
> > On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote:
> > > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote:
> > > > > Finally, note what happens if there's a thread trying to deliver
> > > > > events
> > > > > *while* QCoreApplication is being shut down: notifyInternal() is
> > > > > probably
> > > > > dereferencing a dangling pointer.
> > > > 
> > > > Good point.
> > > > But one might argue that thread should be finished before the
> > > > QCoreApplication is destroyed.
> > > 
> > > Yeah, that sounds like the solution, but just look at both attempts to
> > > cause QProcessManager's thread to exit:
> > > 
> > > https://codereview.qt-project.org/60586
> > > https://codereview.qt-project.org/102526
> > > 
> > > For QtDBus, I could hook to QCoreApplication's destruction, close the
> > > connections, activate the pending replies with a Disconnected error, and
> > > stop the thread. I'd just rather not do it, if it weren't required.
> > 
> > Hi everyone
> > 
> > Albert has just told me that this is also hitting now KUniqueApplication
> > with the new QtDBus changes. The reason is that the auxiliary thread isn't
> > processing events before QCoreApplication is created, so no D-Bus calls
> > complete. In fact, I'm pretty sure this causes the auxiliary thread to go
> > on a busy-wait (100% CPU usage) because it registers socket notifiers that
> > become readable, but never reads from them.
> > 
> > I'd like some opinions on whether we should try this or not.
> 
> Note another problem: if a thread is running and delivering events while the
> QCoreApplication gets destroyed, the application will have several race
> conditions:
>  1) data races accessing QCoreApplicationPrivate::is_app_closing
>  2) TOCTOU race in QCoreApplication::sendEvent for the existence of
> QCoreApplication
> 
> So I have to ask: do we NEED to use QCoreApplication::notify() virtual
> outside the main thread?

The documentation clearly says so, and therefore it is not entirely unlikely 
that somebody relies on that behavior :(

(as much as I dislike it :)


Would it be feasible to make event loops started before and after 
QCoreApplication truly independent from notify() but all the others "join" in?


Simon



More information about the Development mailing list