Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22505
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <441AC0A4.3030306@ctindustries.net>
Date: Fri, 17 Mar 2006 08:59:00 -0500
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Wez Furlong <kingwez@gmail.com>
CC: Dmitry Stogov <dmitry@zend.com>, internals@lists.php.net
References: <000001c649b6$8668abc0$6e02a8c0@thinkpad>	<441AA4FB.9000209@ctindustries.net> <4e89b4260603170533p529a7bcdh92bd0653ad493c01@mail.gmail.com>
In-Reply-To: <4e89b4260603170533p529a7bcdh92bd0653ad493c01@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Problem with ext/libxml RINIT/RSHUTDOWN
From: rrichards@ctindustries.net (Rob Richards)

I don't think I made myself clear on the globals. The only situation 
there would be a problem is if PHP were built threaded and libxml2 were 
not (which as of 2.5.8 it is built threaded by default).

When running threaded, each thread has its own global state, so when 
modified at request startup/shutdown the global is only changed for that 
thread, rather than being set at the module startup/shutdown which would 
set the default values used to initialize the global states of the threads.

Rob

Wez Furlong wrote:
> Sounds like a nasty situation.
> I don't think it's possible to sanely restore the handlers at
> rshutdown in a threaded build without screwing up the other threads
> that are currently executing.
>
> My suggestion is to not restore the handlers for threaded builds, and
> if there is a library sharing/abuse issue, then treat it as an
> installation/configuration problem for the person deploying it (eg:
> don't do that!).  There's not much you can do about that without
> rewriting libxml2 to not use globals for the callbacks.  :-/
>
>   
>