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

[Morten Sørvig]

> On 30 Aug 2017, at 09:30, Olivier Goffart <olivier at woboq.com> wrote:
> 
> Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
>> On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
>>> Which we just rediscovered :) Funny though, apparently 1 misdirected
>>> startTimer() call can turn any application in a CPU hog that burns cycles
>>> without ever doing anything. Wouldn't it be safer for
>>> QObject::timerEvent()
>>> to kill any timer that triggers it, possibly even do an abort if it can do
>>> some kind of runtime debug mode detection? At least then it's set to a 0
>>> (zero) interval?
>> 
>> Sure. Please tell that to Eirik and Håvard back in the early 90s when
>> they're designing Qt.
>> 	http://doc.qt.io/archives/2.3/qobject.html#4c6b67
>> 	(Qt 1 docs not online)
>> 
>> Unfortunately, we can't change anymore.
> 
> We can change the documentation and recommend against using killTimer and 
> startTimer. QBasicTimer should be used instead. This would have probably 
> avoided the problem in this case (as one would have called stop instead of 
> m_updateTimer = 0). And in general is easier to use for 0 overhead.

There is also the option of creating new API that better covers the use case of
running a pice of code once when control returns to the event loop. In use this
could look something like this:

QCocoaMenu::scheduleUpdate()
{
    if (m_updateScheduled)
       return;
    m_updateScheduled = true;

    this->QObject::schedule([&m_updateScheduled, m_nativeMenu](){
	m_updateScheduled = false;
        [m_nativeMenu update];   
    });
}

or even:

QCocoaMenu::scheduleUpdate()
{
    this->QObject::scheduleOnce(&m_updateScheduled, [m_nativeMenu](){
        [m_nativeMenu update];   
    });
}

Morten