Re: [xml] register i/o callback functionality

[Mike Hommey <mh glandium org>]

Rob Richards wrote:
> Within the php/xml integration it looks like we hit a problem with the way we are integrating php streams and 
> libxml. Currently we are registering the streams when php is loaded, which someone has reported is messing up 
> their apache module. And idea was proposed that the callbacks get registered on the request startup and 
> destroyed and request shutdown.
>
> Looking at the libxml code, would this even solve the problem we are seeing, as it seems to me that the the 
> callbacks are registered globally so even if they were set on the request startup, our streams functionality 
> would still leak into other modules during the request as it doesnt look as if the callbacks are able to be 
> defined on a per thread basis. Also, there could be a possibility that while someone is trying to match 
> against the registered streams, someone else could be in the middle of destroying the streams.
>
> Can any one shed any light on this for me and if there is a possible way to work around this (assuming I am 
> not off base in regards to registering them at the request startup)?

While talking about libxml in apache environment, I was wondering 
recently what may happen when several apache modules, using libxml2, 
call the InitParser and CleanupParser functions. When there is only one 
module, thus one call, that's fine, but what happens when there are two ?
A typical case would be : the user changes the configuration of apache 
to disable the php module, then reloads apache configuration. That 
doesn't kill apache, but that unloads php, thus calling the domxml 
unload function, thus calling CleanupParser. Now, what happens in an 
other module using libxml2 after that ?
And I guess the Init/CleanupParser is not the only case of such 
potential conflicts...

Cheers,

Mike