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.