Thiago Macieira wrote:

Oops, missed this one.

> Unfortunately, we can't change anymore.

Can someone explain what could possibly be broken by changing this? Can the 
current base-level QObject::timerEvent() be used for anything constructive 
other 
than heating the office or preventing a CPU core from going to sleep?
I only made my suggestion because it seemed rather evident that anyone using 
the 
QObject timer would override the timerEvent() method.

That said, it does seem a bit overkill to give each and every instance 
inheriting QObject timer features. Most will presumably never use that in a 
typical application, would they?

>> It took me an unreasonable amount of time trying to figure out the reason
>> for the burning, the fact that QCocoaMenu::timerEvent() could be being
>> called as fast as possible and for nothing occurred to me only after trying
>> all other possibilities. And I knew only the timer change could be the
>> culprit; I can only imagine how much more time I'd have spent if this bug
>> had been latent for a few months.
> 
> i'm glad you found it.
> 
> How did you?

How did I discover the issue? I have a top-of-the-2011-line laptop i7 in a 13" 
MBP, and no airco. One tends to notice when it gets busy and remains busy when 
you're not expecting it, and you know something's wrong when a quick look in 
`top` shows nearly 100% CPU for an application that appears to be doing nothing 
(KDevelop in this case, and fortunately I discovered afterwards that Assistant 
worked as a demonstrator too).

Found the bug/fix? The usual way, reverting all changes and restoring them in 
order of least likely culprit. Then by generating trace output, evidently I 
thought last of putting it *before* the timer ID check, and then I had to 
consult the docs to confirm that one indeed needs to kill the timer when done. 
I'd never have guessed that a noop event handler callback could have pump this 
many resources. 

> Actually, there is an overhead, albeit very small one: the timer ID is stored.

Indeed, I wondered about that, and then let it pass because the compiler will 
probably optimise it away.

R.

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to