[Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

[Thiago Macieira]

On Wednesday, 30 August 2017 17:17:32 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > It makes QTimer possible.
> > That sounds quite important to me :-)
> 
> I guess so :) I still don't get what purpose calling QObject::timerEvent()
> has if the method itself does nothing. Gives me something to ponder.

Again, that's what makes QTimer possible.

void QTimer::timerEvent(QTimerEvent *e)
{
    if (e->timerId() == id) {
        if (single)
            stop();
        emit timeout(QPrivateSignal());
    }
}


> > function, because it would break the existing code. And we can't make it a
> > single shot because it would be even worse: it would silently would
> > equally
> > break existing code that expects the timer to repeat itself. This code is
> 
> You're making me doubt. If some class inheriting QObject provides its own
> QFoo:timerEvent() as I understand it should, QObject::timerEvent() isn't
> called, right? Is there code that makes that call explicitly?

This is the same as any event override in Qt, which is basically the same as 
any virtual function override in C++. The overriding function gets to decide 
whether it needs to call the base implementation for something.

QObject::timerEvent does nothing, but other QObject::xxxEvent functions might, 
ditto for QWidget::xxxEvent().

> > And how would we even achieve this? The only way I can think of is to make
> > those functions private (a Qt 6 change) and add the whitelisted classes as
> > friends.
> 
> What's to stop you (in some future Qt major version) from moving the timer
> features to a dedicated QObjectTimer class, forcing code that relies on the
> feature to inherit that class in addition to QObject?

Source compatibility. Which is why it's unlikely we'll do it.

That said, it's not a horrible idea to move this out of QObject. We don't have 
an equivalent watchSocket() function that registers socket notifiers -- we make 
people use QSocketNotifier instead.

> > Ok, so you found by git bisect (or similar) action. I was hoping you had
> > some interesting way of debugging that the problem is timers constantly
> > firing. I
> Sadly, no. A boring way:
> 
> QCocoaMenu::timerEvent(...)
> {
>     qInfo() << $somethingSnarky;
> 
> 
> I did try monitoring the process with Instruments but that failed to attach.

But how did you find out it was a timer? And that it was a timer in QCocoaMenu?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center