Olmo - That alone is not sufficient - that's what we originally used as well.
See this ticket: http://dev.jquery.com/ticket/991 and this blog post: http://alex.dojotoolkit.org/?p=528 YUI, Dojo, and jQuery all use this technique to avoid these leaks. It's unavoidable otherwise. --John On 8/27/07, Olmo <[EMAIL PROTECTED]> wrote: > > John, > > I've been doing some digging to find that leak and I believe it had > been resolved since the 5th ticket in our Trac. > http://dev.mootools.net/ticket/5 > > I also don't encounter any leaks in my own tests. > > -Olmo M. > > On Aug 25, 8:30 pm, "John Resig" <[EMAIL PROTECTED]> wrote: > > > I just took a look at prototype.js andmootools.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&filena... > > > > 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 > >
