[Development] Allowing event delivery prior to and after QCoreApplication

Thiago Macieira thiago.macieira at intel.com
Mon Apr 13 22:23:29 CEST 2015


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.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list