On Fri, 24 Aug 2007 16:47:58 +0100, Dan Janowski <[EMAIL PROTECTED]> wrote:
> If things are being freed unintentionally, then there are not enough > ruby to ruby cross-references to maintain integrity during mark and > sweep. A single ruby object holding on to an xmlNode should inhibit > collection of an entire tree. Individual ruby xml nodes can be > reaped, but there should be no xmlFree done by anything but the > document level object. As for an xmlNode that is not associated with > a document, it must call xmlFree (the xmlNode already indicates if it > is associated with a document) if it has no parent. Which effectively > translates into the same document semantics. Sounds good to me. I take it you'll also mark the ruby-side document object from the node's mark function? > > One operational change should be once an xmlNode is associated with a > document it cannot be associated with another one (at least using the > implicit copy mechanism provided in ruby_xml_node_child_set). The > ruby xmlNode becomes changed and reflects its association with the > document. However, using xmlCopyNode, it is possible to get a copy of > the node without an association to the document and also libxml2 > handles propagation of namespaces. This new copy preserves the > document based free condition above, and also makes it easy to put it > into another document. Not sure if this should be automatic (thinking > not) or an overload of .dup. > I agree with Sean that we're going to have to be more willing to duplicate libxml objects within the binding. The whole reference counting thing was aimed really at avoiding copying, with the rationale that the binding should be as fast and low-footprint as possible. However, with the problems it's caused I'm now of the opinion that we should remove reference counting, make copies everywhere it's even remotely necessary, and then when the damn thing works look again at optimizing out some of that copying. > This should establish a bright line between libxml2 and ruby for > managing memory. > > This is from only a few hours looking at the docs and source code for > libxml2, the python interface and the ruby interface. If these seem > to ignore some known pitfall, please let me know. If not, this should > fix this scope of the memory problem. > > I intend to do this within a week. Post your warnings or wish me luck. > Good luck! > Dan > > > On Aug 23, 2007, at 14:25, Sean Chittenden wrote: > >> Having spent a great deal of time with this, I'm now of the following >> opinion of this library: when initially writing this module, I >> exposed too much of libxml to Ruby and the memory models and object/ >> tree dependencies and interactions between memory and objects is... >> problematic and should be reviewed. $0.02. -sc > _______________________________________________ > libxml-devel mailing list > libxml-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/libxml-devel > -- Ross Bamford - [EMAIL PROTECTED] _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
