Pops, this problem occurred in jQuery because of the heavy usage of closures, especially in the case of onreadystatechange (as explained in the article posted in the jQuery ticket). It never occurred for example in MooTools because the onreadystatechange handler is a class method and not a closure. The easiest fix, instead of using a periodical checker which seems kind of weird on the first blush, is to avoid closures during coding (like in MooTools, as mentioned above, because of the class/OOP design). Of course every frameworks resets the handler when the request is completed, that's not the problem. I hope this describes the problem and the leaks better and explains the "naive" code of other developers that does not result in leaks.
Harald On Aug 28, 7:36 pm, Pops <[EMAIL PROTECTED]> wrote: > On Aug 27, 11:31 am, "John Resig" <[EMAIL PROTECTED]> wrote: > > > > > YUI, Dojo, and jQuery all use this technique to avoid these leaks. > > It's unavoidable otherwise. > > John, > > I'm curious. Been catching up of the technical issues and JS/DOM > framework, and it seems to me that a basic part of the issues is > related to closures and anonymous functions and how the JS user agents > deals with it. > > I'm curious if you tried/explored initialize the XHR.readystatechange > handler? How about XHR worker thread pools? or not using a anonymous > function for the handler but a external function? > > I tried all this for IE and FF and under Windows, I don't see any more > leaks. > > I used this suggestion for initializing the hander: > > http://www.volkanozcelik.com/cre8/blog/2006/04/another-way-to-prevent... > > var Constants = { > NULL:function() {} > > }; > > usage> xml.onreadystatechange = Constants.NULL; > > -- > HLS
