I've been looking at the code in Timer.cpp lately, and I have a vague worry that there might be problems, but no real concrete testcases of something actually being wrong.
When firing timers, we set a single system timer for the soonest timer. When it goes off, TimerBase::fireTimers() sequentially pulls off all the timers in the ready queue and fires them. This firing is done via callback directly to the fire handlers, which can take arbitrary time to execute. More worryingly, we process all timers before returning to the global message loop. I'm concerned that setting a large number of timers, or having handlers that take a while to execute, could cause poor performance/responsiveness due to starving the global message loop. The Mozilla timer system gets around this problem by posting individual messages to the main message queue for each timer that needs to fire instead of directly calling back to handlers from the timer-processing loop. However, this means the actual firing of each timer is additionally delayed by other processing other items in the message queue. Also, a careless design for this could queue up multiple "timer fired" messages for a timer that was behind on processing them. (Imagine an autoscroll timer set to repeat every 100 ms, and a page that took a long time to do individual paints. Multiple scroll messages might queue up by the time the user's mouse input messages could be processed to cancel the scroll, leading to scrolling continuing for a while after the user had cancelled.) Still, even with these concerns, I wonder if the Mozilla system might not be better. Any thoughts on particular cases that would perform poorly in either system, or whether this change would be beneficial? Don
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
