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

Lars Knoll lars.knoll at qt.io
Wed Aug 30 10:06:35 CEST 2017


On 30 Aug 2017, at 09:30, Olivier Goffart <olivier at woboq.com<mailto: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.

+1. Maybe even deprecate startTimer and killTimer?

Cheers,
Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170830/ce6de22c/attachment.html>


More information about the Development mailing list