Re: Coexistence of libxml++ and libxml2 in the same process



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.



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