Re: [xml] register i/o callback functionality

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



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