On Jan 11, 2007, at 7:10 PM, Don Gibson wrote:
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.
I see your point about the theoretical problem, but we haven't seen
an actual problem in practice. WebCore itself does not send that many
timers, and JS timers have a minimum delay interval, so it's hard for
them to starve the event loop. I guess an interesting test case would
be to make a web page that sets a huge number of JS tiers that go as
fast as possible and do lots of work, and see if it hurts
responsiveness. I'm not sure how likely a scenario this is, except
possibly as an attempted denial of service attack.
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?
The Mozilla system would probably make everything relying on a timer
marginally slower. If starving the event loop turns out to be a
problem, I think it would be more sensible to set a maximum time
interval for which timer handlers will be processed (after which
another zero-delay timer is set) than to force each timer handler
onto its own run loop thread.
But anyway, like I said, we haven't seen any real-world
responsiveness problems due to this setup, and failing that I am not
inclined to worry about it.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
