On Apr 21, 2004, at 2:36 PM, Paul Querna wrote:
The libxml2 Extension in PHP5 uses
xmlSetGenericErrorFunc(NULL, php_libxml_error_handler);
This globally(inside the process) sets the libxml2 error hander to PHP's
own function.
Why is this bad?
It clobbers the processing done by anything else that uses libxml2 in the same process as PHP.
For a simple example, I use mod_transform ( http://svn.outoforder.cc/svn/mod_transform ) with Apache 2 as a filter to process XML documents w/ XSLT into HTML. If there are _any_ errors in the transformation PHP attempts to take care of them. This causes Apache to crash because this is not even a PHP request and very quickly the Error Handler will crash when it tries to get a server context.
This is not an issue isolated to Apache 2. It could happen in Apache 1.3 if any other module used libxml2.
Nope - it couldn't. We reset (or we should) the error handler after we are done executing. In processes, only one thing executes at a time, and when PHP is executing we want to override this error handler.
The proper way for PHP to handle this is to not set a Generic Error function, but rather check the return values of libxml2 functions.
Nope.
This is not like the local-mysql vs system-mysql problem that used to be
more common. PHP is initializing libxml2 as if it was the only user,
which is not always the case.
Its actually quite different than that problem. This is a problem for people who use threads. People who use threads for serving dynamic webpages with PHP should be castrated and then shot (well, at least castrated, we don't want this problem proliferating.) The solution here is either to use a global context of our own, if libxml2 allows us to do so, use a mutex, or just laugh very hard and very loud when people tell us they have a problem using php in threaded environments. On that note....
bwahhhahahahhahahaha.
-Sterling
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
