Re: [PHP-XML-DEV] libxml2 memory handling

Working code to see what I am talking about is at
www.ctindustries.net/domxml_test.zip
If you need a tar.gz file, let me know and I will put one up there. I didnt
dump this into the test project as it is radically different than the
origional and contains a lot of test code. Really just to get a proof for
this going and check out how things are handled in various scenarios.

From: "Christian Stocker" <[email protected]>
> 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-249F15B
A).
> (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 ;)

For an unset I have it freeing the libxml2 structures, just wasnt sure about
children nodes (which you answered at my last question). Test code had the
children just being unlinked if they were referenced as I wasnt too sure
here.

> 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?

libxml2 leaves all of this up to the developer to handle. I have been going
through the tree.c file and when freeing a doc, it traverses the tree and
frees the strcutures within (no regard to nodes not within the tree but
belonging to the document).

> (see http://mail.gnome.org/archives/xml/2002-May/msg00183.html for
> details) could also be a solution for the whole problem.

heh, didnt look like anyone wanted to approach answering this.
I had briefly look at callbacks - was checking out gdome, a lot to go
through, but started in code by handling these scenarios (basically seeing
what libxml2 is going to do and then coding for the extension prior to
making the libxml2 calls).

Why I brought up using a list to node pointers on a document domxml_object,
is that with the new engine, we could handle this in our domxml_objects_dtor
sction of code. When a doc is freed, before calling its destruction code, it
would go through the list and handle those additional (non linked) nodes -
if nodes must have a doc, then the references to the node must be unset and
the nodes freed - otherwise would have to set their doc to NULL. This last
portion is not implemented in any fashion as just ran into this the other
day.

> 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...)

> I would expect, if I free (unset()) a object, that all its children  are
> also unset.

Will look into this one further to see if there is any "standard" across the
apis out there. Could also keep it set and just remove the underlying
pointer to the xml structure, so the user would get a warning/error that the
object is not of type XYZ.

Rob