I've ported the test to: http://ibolmo.no-ip.info/sandbox/ajax-leaks.html (note: it might be offline in a few days-- I'm moving :D).
Can't seem to reproduce the leaks. Let us know if you experience any. Like I said, I had believed this had been taken cared of since the 5th ticket. I did find it weird that in the past 8 months no one had mentioned any onreadystatechange leaks. MooTools takes these sort of issues very seriously, and we dont think that we have been naive in our implementations. We have even implemented our own Garbage Collector to deal with unwanted attribute leaks. Never hurts to check, however. Thanks, Olmo M. On Aug 27, 10:31 am, "John Resig" <[EMAIL PROTECTED]> wrote: > 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
