Re: [xml] Relaxng memory discipline (Python bindings)
- From: Daniel Veillard <veillard redhat com>
- To: Anthony Carrico <acarrico memebeam org>
- Cc: libxml <xml gnome org>
- Subject: Re: [xml] Relaxng memory discipline (Python bindings)
- Date: Thu, 14 Aug 2003 05:32:37 -0400
On Wed, Aug 13, 2003 at 11:39:23PM -0400, Anthony Carrico wrote:
I'm trying to figure out the relaxng memory discipline under Python
1. Whereas xmlNode uses manual free with xmlNode.freeNode(), the
relaxNgParserCtxt seems to rely on the garbage collector's __del__
callback. It seems like manual free is also possible using
relaxNgParserCtxt.relaxNGFreeParserCtxt. Is it fine to use this manual
free? Shouldn't relaxNGFreeParserCtxt set self._o to None to prevent
__del__ from calling xmlRelaxNGFreeParserCtxt twice?
2. Same issue for relaxNgSchema.
3. Same issue for relaxNgValidCtxt.
4. Is it ok to free the relaxNgParserCtxt before the relaxNgSchema
(and keep using the relaxNgSchema)?
5. Is it ok to free the relaxNgSchema before the relaxNgValidCtxt (and
keep using the relaxNgValidCtxt)?
6. How does libxml2.relaxNGCleanupTypes() fit in? Does this just clean
up some global state that is automatically created anytime you use one
of the relaxNg procedures?
Have you read http://xmlsoft.org/python.html ? That sounds like a good start.
Also note the need to explicitly deallocate documents with freeDoc()
. Reference counting for libxml2 trees would need quite a lot of work to
function properly, and rather than risk memory leaks if not implemented
correctly it sounds safer to have an explicit function to free a tree. The
wrapper python objects like doc, root or child are them automatically
Document tree cannot be garbage collected by python. All wrapper objects
GC'ed, all objects which do not pertain to a tree are too. And the reader
doesn not build a tree... Reading the examples helps too they explicitely
check for memory leaks.
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev