From: Sterling Hughes
> Err, read back in the message. Specifically about "should reset the > generic error handler." If it doesn't reset it, that's a separate > issue. It has *nothing* todo with the mysql issue (which was symbol > conflicts due to two libraries being compiled into the same server). A > process can not execute two code paths at the same time, therefore you > cannot have such corruption in a prefork model. Sterling, I also thought this might be in issue when I brought it up many moons ago as I have no idea of the isolation in apache. I just ran a debug session using apache 2.0.45 prefork under linux. MINIT is only called on server startup and MSHUTDOWN is only called on server shutdown. Since the error handling is set/unset in this spots, it gets changed to our internal handling when apache first starts up and isn't reset between requests. Only when apache shuts down is it reset. Now either the apache 2 sapi is wrong in this regard or the error handling really needs to be re-worked. Here are a couple options I can think of: Putting it in the RINIT/RSHUTDOWN should fix it (cant say about threaded servers and threaded libxml as there was an issue with the per thread error handing in libxml up to at least 2.5.11 - threaded libxml builds needed xmlThrDefSetGenericErrorFunc to be set in the main thread which would have to happen in MINIT (or the error handling needs to be set on every request) - had only played around with this on windows though so not sure if it affects non threaded web servers as well), not sure if this is ideal since it would need to be run on every request wether using libxml or not. If libxml error messages are only needed during loading of xml and possibly some other spots where we have a context (such as SAX and possibly validating, etc.. - havent looked at that), the custom error functions can be attached directly to the context. Origionally I moved those custom error functions to the libxml extension (as they used to only be used in dom in th is manner) so that this could be the case, but ended up with just setting the global error handler instead. For all other errors when dealing with operations on the tree, would have to deal with errors through the extensions alone. My suggestion is to pull the 2 calls to xmlSetGenericErrorFunc from libxml.c right now so that is resolved prior to RC2 going out the door (if possible). Then just have to decide wether this should be worked on and implemented prior to the 5.0 release or put on the list for 5.1. Feel free to tell me if I am way off base here as I really have no idea of the interaction between modules in apache :) Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
