The problems that I have discovered stem from libxml freeing entire document trees while there are still ruby objects referencing the nodes. When those ruby objects are subsequently garbage-collected, the xmlNodes in those objects have already been freed and sadness ensues. But I think the current mechanism is so close to working that it does not warrant a complete rewrite.
Why would a Ruby object "own" a xmlnode in a document tree? Can that be avoided?
If not, can you install a callback into libxml to be alerted when a node is freed? If so, then you could decrement the reference count. But you'd still have to keep some long-term memory around so that any existing Ruby objects pointing to the node could check the reference count and see if it is zero. How do you know when to free that memory? I see no way, unless you go to the Ruby object <-> libxml object mapping like I described in the last email.
As far as I can see, all trees should simply be walked prior to callingXMLFree to check for nodes referenced from ruby.
Yes, that is another approach. It would still require mapping ruby objects to libxml objects. Unless you want to use object space and iterate over Ruby objects that way.
It would be easier to avoid the whole issue, and not have the Ruby objects own the libxml objects at all. You would have an issue that a programmer would have to make sure not to use a Ruby object pointing to an invalid libxml object though.
If it weren't so close to working already I'd probably be keen to see such a proven approach used, even if it is tricky. As it is, I'd prefer to see reasonably simple bug-fixes applied. Not my choice though - I'm not one of the project developers so I'll butt out now :-)
Your insights are much appreciated, please keep contributing your thoughts :)
Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
