I've a proposal, the code could be modified to call xmlRegisterNodeDefault before any xmlNew* call and to reset the handler to the default one after that. This approach would preserve the current interface while making libxml++ less intrusive. I'm working on a patch to implement this solution, any comment? Regards, Alessandro On Wednesday 03 November 2010 13:55:33 you wrote: > Hi everyone, > > while trying to use the libxml++ in a browser plugin project (namely > lightspark) I've discovered that libxml++ seems not designed to coexist > with unwrapped usage of libxml2 in the same process. This is caused by the > static initialization and destruction done by Document::Init, I'm > reporting the snippet here for convenience > > Document::Init::Init() > { > xmlInitParser(); //Not always necessary, but necessary for thread safety. > xmlRegisterNodeDefault(on_libxml_construct); > xmlDeregisterNodeDefault(on_libxml_destruct); > xmlThrDefRegisterNodeDefault(on_libxml_construct); > xmlThrDefDeregisterNodeDefault(on_libxml_destruct); > } > > Document::Init::~Init() > { > xmlCleanupParser(); //As per xmlInitParser(), or memory leak will happen. > } > > So the xml system is uninitialized when libxml++ is unloaded, even if there > are other users of libxml2 still living. Moreover, every xml node creation > go through libxml++ handlers, and this causes crashes here and there if > the calling code is expecting to use normal libxml2. > > Any idea to make libxml++ more robust to such issues? > > Regards, > Alessandro Pignotti
Attachment:
signature.asc
Description: This is a digitally signed message part.