Re: [PHP-XML-DEV] 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      [email protected]
wor...+41  1 240 5670      gpg...0x5CE1DECB