M
> To: Dmitry Stogov
> Cc: 'Wez Furlong'; 'Rob Richards'; internals@lists.php.net
> Subject: Re: [PHP-DEV] Problem with ext/libxml RINIT/RSHUTDOWN
>
>
> Hello Dmitry,
>
> which is the default
>
> however we could for optimization add
ternals@lists.php.net
>> Subject: Re: [PHP-DEV] Problem with ext/libxml RINIT/RSHUTDOWN
>>
>>
>> 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 th
BTW: libxml can be compiled with LIBXML_THREAD_ENABLED.
Dmitry.
> -Original Message-
> From: Wez Furlong [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 17, 2006 4:33 PM
> To: Rob Richards
> Cc: Dmitry Stogov; internals@lists.php.net
> Subject: Re: [PHP-DEV] Probl
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
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 i
Dmitry Stogov wrote:
Hi Wez,
I found a bad code in ext/libxml.
On each request startup/shutdown it changing some libxml callbacks.
At first this slowdown each request, at second multi-threaded PHP may fail,
because different threads may set/clean the same callbacks in the same time.
May be it
Hi Wez,
I found a bad code in ext/libxml.
On each request startup/shutdown it changing some libxml callbacks.
At first this slowdown each request, at second multi-threaded PHP may fail,
because different threads may set/clean the same callbacks in the same time.
May be it is possible to setup th
