[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