[Development] Allowing event delivery prior to and after QCoreApplication

Thiago Macieira thiago.macieira at intel.com
Tue Apr 14 01:53:11 CEST 2015


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.

https://codereview.qt-project.org/110325
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list