On 21 Mar 2010, at 09:10, Niels Grewe wrote: > On Sun, Mar 21, 2010 at 12:48:00AM -0000, David Chisnall wrote: >> Made ETXMLNullHandler destroy itself when it finishes parsing. The >> way this is done violates some of the standard OpenStep memory >> management idioms. It's worth fixing this properly at some point, but >> it will require changing things in XMPPKit. Currently, subclasses of >> this in XMPPKit are just leaking - they're allocated with +alloc and >> never released. Ideally, they should probably be using a named >> constructor, rather than +alloc. The old code, which was doing [self >> retain] in -setParser: was clearly wrong, but in a different way. > > My idea of a proper fix would be to have user code allocate autoreleased > handlers if they are not needed after parsing. We would then have the > parents keep track of their children (just add them to an array) and > remove them on -endElement:. If that sound's reasonable I'll take over > the job of doing that (in XMPPKit and EtoileSerialize as well).
I don't really like the idea of autoreleasing the handler, because it is then not collected until the autorelease pool is destroyed, which i typically after parsing has finished. This means that the memory will not be released for a long time, and the total memory usage for the parser becomes O(n) in terms of the number of XML elements. With the current implementation, it's O(n) in terms of the maximum depth of the tree, which is a lot better. So, semantically what I'm doing now is probably right, but in terms of interface it is not. I think the best solution is to adopt something like NSTimer's constructor for a registered timer, and document that they should not be created with +alloc. This idiom would then need to be adopted everywhere that the code is used, which is why I did not do it last night (I just spotted the leak while working on EtoileText). If you want to make these changes, then please do! David -- This email complies with ISO 3103 _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
