Re: libxml2 memory handling

On Sun, 20 Apr 2003, Rob Richards wrote: > I am working on redoing the memory handling so that the new extensions will > no longer use need the resource destructors, but rather work as normal > objects do with no regards to when or how the objects are destroyed. This > would not only relieve us of worrying about the order things are freed but > also allow for the objects to work as they should (i.e. calling unset would > actually unset the object and clean up the underlying libxml trees and > memory). good idea. But the main problem here (as you also encountered) is that there is nothing about actually freeing stuff in the DOM-Standard (http://www.w3.org/TR/2003/WD-DOM-Level-3-Core-20030226/core.html#ID-249F15BA). (DOM-)unlink is not the same as (PHP-)unset and we should be carefull, what happens if we unset a node without too much WTF factorness for the endusers ;) > There are a few certain instances that it will cause a problem. The problem > occurs when a document object is destroyed and the tree is freed before > nodes wihch are not part of the tree, but owned by the doc. A few libxml2 > calls use the doc property for some of its calls, and these crash. There are > a few ways to deal with it, but I wanted to know what people think as both > will involve a few steps that would need to dealt with when writing some of > the functions. I am also not sure of all the ramifications of some of the > possible solutions, so if anyone can see any or can see a better solution to > this, let me know DOM-Standard says, that an object always belongs to a Document. I know, it's possible to create elements within PHP, which do not belong to a Document, but I was never very happy with that.. > One possible solution is when unlinking nodes and creating nodes, which have > not been added to the doc, is to set their doc to NULL, add a doc pointer or > its address to the domxml_object structure and use that to do validate the > doc conditions prior to performing appends, etc... Mmmh, "having a doc" is not the same as "being in the tree". Therefore I think, we still could use the "doc" property to know to which document the object belongs. But I see the problem with freeing the document and not freeing nodes, which do not belong to the tree.. How does libxml2 handle that? Maybe: xmlRegisterNodeDefault(xmlRegisterNodeFunc f) register the callback for "hey, there's a new node now" xmlDeregisterNodeDefault(xmlDeregisterNodeFunc f) register the callback for "hey, this node will be gone in a few ticks" (see http://mail.gnome.org/archives/xml/2002-May/msg00183.html for details) could also be a solution for the whole problem. > the libxml calls should > take care of setting the doc properly when appending (or we could do that > ourselves when needed). > > Another possible solution would be to add a list to node pointers on the > domxml_object of a document which any time a node is unlinked or created, it > would be added to this list. This list basically would contain the nodes > which the document owns, but are not part of the tree. When a document > object is freed, it would first go through this list and set all the nodes > doc property to NULL (or we could destroy these objects) and then go ahead > and free the document. This would require any unlink, replace, etc... to > have to add and/or remove the node pointer from this list so that the list > is properly maintained. The problem with this is, that libxml2 sometimes does funky stuff with its nodes, especially when it comes to text-nodes and you never know what actually happens behind the scenes (it sometimes tries to merge to adjactent text nodes, which caused us a lot of troubles...) > This brings up the last point on when should nodes be unlinked and when > should nodes be freed? There really is no defined way to handle this in the > specs. Take for instance, the case when you have an object pointing to an > unlinked element. You also have an object pointing to another element > further within the tree of the unlinked element. The top level element is > being destroyed, should the child be freed (thus destroying the object > associated with this node) or should the child be unlinked from the tree? I would expect, if I free (unset()) a object, that all its children are also unset. chregu -- nam...christian stocker adr...pflanzschulstr. 31, ch-8004 zurich pho...+41 43 317 9984 www...http://blog.bitflux.ch mob...+41 76 561 8860 ema...chregu@phant.ch wor...+41 1 240 5670 gpg...0x5CE1DECB