Just reporting back, as I suspected, you won't avoid preserving the outer function's context by creating an anonymous closure to create the closure, the entire scope chain is preserved until the request completes and the reference to the request is released (which allows the references to the closures to be released, which releases the scope chain of call objects -- "activation objects" in ECMA parlance -- since the only remaining references are circular). Sorry for giving the wrong impression earlier, even if it did come with a caveat. :)
But in any case, since the XHR call *will* complete (successfully or otherwise), and the request will be released, this isn't a memory leak. It uses memory for a little while (for a good purpose), but doesn't leak it. -- T.J. Crowder tj / crowder software / com On Feb 24, 11:25 am, "Manu Temmerman-Uyttenbroeck" <[EMAIL PROTECTED]> wrote: > Thx a lot for helping me visualize it! > > On Sun, Feb 24, 2008 at 11:08 AM, Andrew Dupont <[EMAIL PROTECTED]> > wrote: > > > > > On Feb 24, 1:31 am, "Manu Temmerman-Uyttenbroeck" > > <[EMAIL PROTECTED]> wrote: > > > The basic example onhttp://prototypejs.org/api/ajax/requestalsohas a > > > closure, because the onSuccess callback function is defined inline, > > correct? > > > So if that 'new Ajax.Request' is in a function, then that url variable > > will > > > not be released until that ajax request successfully finishes and that > > > onSuccess function runs? > > > What happens then when the ajax request is not successfull and throws an > > > exception. That url value will stay in memory until you navigate away > > from > > > the page? > > > Unless the request object itself gets dereferenced. > > > If I'm inside a function and I say... > > > var foo = new Ajax.Request(/*...*/); > > > ... then once the function goes out of scope, I won't be able to > > obtain a reference to it again. (This is assuming that variable isn't > > a part of *some other* closure created inside the function. The > > browser knows this, so when the request has completed its life-cycle > > (even by throwing exception), it'll GC the object if nothing > > references it. And that would also GC the closure formed by attaching > > that anonymous function to the object. > > > Now, if I say... > > > window.foo = new Ajax.Request(/*... */); > > > ... then I've set a global reference that will never go out of scope. > > That means my request object won't be GC'ed unless I explicitly > > dereference later on (window.foo = null). > > > Let's make a diagram. Think of "window" (the global scope) as a big > > circle in the middle of the page. Imagine everything -- strings, > > numbers, objects, etc. -- as nodes. Now draw lines between nodes to > > make references. (window connects to Ajax, Ajax connects to > > Ajax.Request, etc.) > > > Anything that can be traced back to "window" must be kept in memory. > > If I remove a reference to something, that erases a line from the > > diagram, and any resulting "node island" can be GC'd. Even if you've > > got two objects that reference one another, if neither one of them can > > be referenced from the global scope, they can be purged from memory, > > since it's impossible to refer to them. > > > (Of course, IE has its own problem with circular references, which > > brings me to your next question...) > > > > What happens when you didn't only store a url string, but let's say a > > > reference to a collection of 200 dom objects and the ajax request fails. > > > Circular reference? Meaning a 'real' memory leak. That memory won't be > > > released even after navigating away from the page. > > > Yeah, and that's the sort of thing that can't easily be solved inside > > the JS environment (except through cautious coding). Of course, IE7 > > claims to have fixed many of those leaks, so maybe you should make a > > test page and find out. ;-) > > > Cheers, > > Andrew --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
