Re: [xml] register i/o callback functionality

[Daniel Veillard <veillard redhat com>]

On Fri, May 28, 2004 at 08:03:21AM -0400, 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)?

  Well, yes, all the I/O integration is designed as a library global 
feature, this is kind of obvious since the registration mechanism doesn't
take any context. So far this was sufficient, because the way the
registration works is by checking the resulting (aboslute) URI for handling.
So for example if someone want to make a custom I/O access it is sufficient
to use names which won't conflict with other I/O extensions. For example
if all the names used were like php5::stream_number, and if the other 
apache module uses amother scheme they can coexist peacefully.
  Now for reentrancy and thread support, it was assumed that the I/O
registration being done at initialization time this would be sufficient
for proper thread handling, because all contextual operations on I/O
(i.e. read/write/close) are context dependant, and only one thread is
allowed to access a parsing context at a given time, so that was supposed to
not be a problem either.
  Now if you come with a realistic example of why you would need per
context registration that might be added. One thing that won't work reliably
is to dynamically register and unregister new I/O handlers. It's better
to register once global entry points and handle potential thread contention
down in the routines, as the registration/unregistration I/O API are not
thread safe.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/