> I just took a look at prototype.js and mootools.js, neither are > depended on a "Lets hope if this best guess 13ms always works" timer > concept.
Right, so they leak every single time you use them, both libraries are quite naive about the issue of memory leaks. If you're looking for some form of justification for what we're doing look at Yahoo UI: http://sourceforge.net/project/downloading.php?group_id=165715&filename=yui2.3.0.zip In build/connection/connection.js look for handleReadyState which does all the polling. Also, Dojo is using this particular method for querying XHR state: http://alex.dojotoolkit.org/?p=528 Yahoo UI is also using a polling interval of 50ms for XHR, which they seemed to just pick arbitrarily. Just to emphasize that point, look in Yahoo UI's build/animation/animation.js where they set their delay on their animation timers to 1ms. I think you're missing a couple points here: - JavaScript engines are not multi-threaded. There's no such thing as a locking or synchronization issue within JavaScript. The XHR request won't return or finish until the current JS is finished executing. - setTimeout and setInterval do not create threads. The push functions onto the JavaScript stack to be executed at a later time (so if a script never stops running a timeout will never be called). - The units passed to setTimeout are arbitrary, it's still at the browsers discretion as to when they're actually executed. They're not sent straight to the processor for handling - all operations are delegated by the browser. So, yes, we might as well pick 1ms, Yahoo UI seems to think it's ok, there's no particular reason for not doing so - nor has it made any particular effect upon the system for not having done so. In the case of Ajax, the query rate could probably be slowed down to something like 50ms, and for animations, increased to something like 1ms. The issues at play here are phenomenally more complicated, and nuanced, then they're made out to be. --John
