Everything

php

[PATCH] libxml - Move Callback Reg to Request Init

php.internals

Paul Querna

22 years ago

Patch Moves the Registering of the PHP XML Streams to the request init,
instead of installing them globaly in the Module init.

This is needed if any other Apache modules use libxml2 on a non-php
request.  If this patch is not applied, any other use of libxml2 in the
same process will likely fail when the PHP callbacks are called.

Thanks,

-Paul Querna

Andi Gutmans

22 years ago

Anyone see a problem with this patch? If not, I'd like to include it in RC3
because it makes sense.

Andi

At 10:13 PM 5/26/2004 -0700, Paul Querna wrote:

Rasmus Lerdorf

22 years ago

Is it not possible to do this at the time set_streams_context is called?
I am weary of having this done per-request for all PHP requests regardless
of whether or not they actually call anything in libxml.

-Rasmus

On Fri, 28 May 2004, Andi Gutmans wrote:

Rob Richards

22 years ago

If you are talking about the libxml_set_streams_context, the php streams are
registered by default so that function is not even used unless explicitly
called to use a specific stream. I also dont see how that patch could work
as in the request shutdown, it calls xmlRegisterDefaultInputCallbacks which
wont do anything as it returns immediately if the callbacks have already
been initialized (it doesnt perform a reset on the streams; They have to be
explicitly destroyed, which would be rebuilt again when needed.

I am not sure how correct my assumptions are here, was just looking at the
libxml code, but am trying to get some more info from the libxml people to
see if they can shed more light on this.

Looking further into the libxml callbacks, the get registered as a true
global and the functions are not reentrant safe. So even if set on the
request, they would be global until destroyed. If they were destroyed on the
request shutdown, it looks like there is a possiblity that someone could be
trying to match a callback while someone else is removing them.

So in short, I'm not sure how isolated we can keep any of the streams
functionality.

Rob

From: Rasmus Lerdorf

> Is it not possible to do this at the time set_streams_context is called?
> I am weary of having this done per-request for all PHP requests regardless
> of whether or not they actually call anything in libxml.
>
> -Rasmus
>
> On Fri, 28 May 2004, Andi Gutmans wrote:
>
> > Anyone see a problem with this patch? If not, I'd like to include it in

RC3

Rob Richards

22 years ago

Is it possible to know wether a function is being called from a php context
or not?

If so, a check could be done in php_libxml_streams_IO_match_wrapper which if
not under the php context, it would return 0 thus making the php registered
streams useless for other applications.

I also got a reponse from the libxml people and they indicate that trying to
register and unregister the streams will not work reliably and basically
they should be registered in the MINIT (where they currently are) to work
correctly.

Rob

Rasmus Lerdorf

22 years ago

On Fri, 28 May 2004, Rob Richards wrote:

> Is it possible to know wether a function is being called from a php context
> or not?

I am not sure how.  We know if we are in the middle of parsing a PHP
script, but that doesn't necessarily mean that the libxml call is from a
PHP context.  We could be calling some 3rd-party library that knows
nothing about PHP that happens to use libxml.  But, when called from a PHP
context then we control the caller, so we could pass along a hint somehow,
couldn't we?

> I also got a reponse from the libxml people and they indicate that trying to
> register and unregister the streams will not work reliably and basically
> they should be registered in the MINIT (where they currently are) to work
> correctly.

Hrm.  I wonder why that is?  But that does mean this patch definitely
shouldn't go in.

-Rasmus

Rob Richards

22 years ago

From: "Rasmus Lerdorf" <rasmus@php.net>

> I am not sure how.  We know if we are in the middle of parsing a PHP
> script, but that doesn't necessarily mean that the libxml call is from a
> PHP context.  We could be calling some 3rd-party library that knows
> nothing about PHP that happens to use libxml.  But, when called from a PHP
> context then we control the caller, so we could pass along a hint somehow,
> couldn't we?

The callback is coming from libxml, which means a hint cant be passed to the
callback (only the URI is sent).

> > I also got a reponse from the libxml people and they indicate that

trying to

> > register and unregister the streams will not work reliably and basically
> > they should be registered in the MINIT (where they currently are) to

work

> > correctly.
>
> Hrm.  I wonder why that is?  But that does mean this patch definitely
> shouldn't go in.

From what is sounds, the patch shouldn't go in. The I/O registrations were
designed as a global library feature and are meant to be called at
initialization time. Much of it has to do with threading and re-entrancy.

Latest followup:

RR > I figured that was the case but wanted to make sure before going down
the
RR > rat hole, so trying to see if there is anything that can be done in our
RR > matchcallback routines.

Since the input is "just" the URI string, and that string may come from
within the document it seems only an API addition is possible, this is
not gonna be easy to design,

Daniel

Andi Gutmans

22 years ago

zend_is_executing() might work, but that is only if this method can only be
called during script execution (which I'm not sure of). I'm also not sure
if this is reset to 0 at the end of each request but that should be easy to
fix.

Andi

At 11:54 AM 5/28/2004 -0400, Rob Richards wrote:

Rob Richards

22 years ago

From: Andi Gutmans

> zend_is_executing() might work, but that is only if this method can only

be

> called during script execution (which I'm not sure of). I'm also not sure
> if this is reset to 0 at the end of each request but that should be easy

to

> fix.

Yup, this method should only be called during a request. I tested it out
with mod_xslt and it seemed to work correctly. mod_xslt would safely exit
from the function ignoring our streams handler. It seems to reset to 0 after
a php script hits it, as a subsequent calls to the mod_xslt handler
continuted to function correctly.  The only question I have is will there be
any problems if run in threaded mode as TSRMLS_FETCH() needs to be called.

Thanks,

Rob

Sterling Hughes

22 years ago

Rob Richards wrote:

> From: Andi Gutmans
>
>
>
>>zend_is_executing() might work, but that is only if this method can only
>
> be
>
>>called during script execution (which I'm not sure of). I'm also not sure
>>if this is reset to 0 at the end of each request but that should be easy
>
> to
>
>>fix.
>
>
> Yup, this method should only be called during a request. I tested it out
> with mod_xslt and it seemed to work correctly. mod_xslt would safely exit
> from the function ignoring our streams handler. It seems to reset to 0 after
> a php script hits it, as a subsequent calls to the mod_xslt handler
> continuted to function correctly.  The only question I have is will there be
> any problems if run in threaded mode as TSRMLS_FETCH() needs to be called.

Well, the threaded case is very much a "who cares" scenario.  Crash once
every hundred requests, crash once every thousand - add them up and it
might be real money some day.

Serially, if someone wants to share a shared library between two
separate third party software products in a threaded environment - i'll
keep them in my nightly prayers.

-sterling