> On 30 Aug 2017, at 09:30, Olivier Goffart <oliv...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development