Re: [xml] Re: error output (again + elaborated)



On Wed, Nov 21, 2001 at 10:05:25AM +0100, robert wrote:
 >Errors are still send to stderr, though :(

I found the reason: xmlInitParser sets xmlParserInitialized to 1 after it
has initialized the internal state of the parser.

However, xmlCleanupParser sets the variable back to 0, which means that
xmlParseDocument() and friends will call xmlInitParser() again (which sets
default error-handlers, outputting to stderr again).

  Ahhh ... now I understand.

Some background: I'm running libxml/libxslt in a threaded environment.
xmlInitParser() is run in a locked part of code because of non-reentrancy;
however, xmlCleanupParser() is called every time I finished handing one
document to avoid memory-leaks.
 
  I don't understand who started propagating the idea that xmlCleanupParser()
should be called all the time. It cleans up the global state of the
library (predefined entities, and predefined languages converters for example).
I SHOULD NOT be called each time a document has been parsed, you're just
wasting CPU cycles and resetting all your default settings.

I'm not fully aware of the intricacies of xmlCleanupParser(), but could
anyone tell me if _not_ calling xmlCleanupParser() introduces leaks? If it
does, I might have a problem.

  Where did you get that stupid idea ? The library allocates document
independant global state. This call frees it and reset the library state.
It should be called *only* when all processing with libxml has finished in the
entire program life. Actually calling this function while you have opened
document may cause serious troubles.

Daniel

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]