Hi, Jeremy Chadwick schrieb:
This is more of a question for Sebastian (the author) than the rest of us, though mailing the list is indeed the right thing to do.I'm under the impression that Sebastian doesn't test suPHP on systems using a threaded MPM, but tests it under systems using the prefork MPM.
I have been flawlessly running my webserver with suPHP and worker MPM for at least several months (probably much longer, but I moved the system some months ago and cannot remember for sure, which MPM was running on the old one).
suPHP itself should be thread-safe as it does not share any data between requests. Configuration data is shared, but this should not be a problem, because as far as request processing is concerned, this is read-only.
On the other hand you are right that multi-threading in Apache is rather new and thread-safety is a difficult topic. So as long as MPM prefork is working and the server is not running at the edge of its capabilities, there is no need for MPM worker.
Regarding the signal / zombies issue discussed some month ago, in fact MPM worker could be causing this problems. At least as far as I have investigated this issue, probably mod_suphp is not causing this issues: The way suPHP is creating a new process, is exactly the same ways other modules are using and the APR API reference does not say anything about signal handlers, so probably Apache or APR should take care of this. Besides a module could not even change the signal mask without affecting the whole server, so doing something like this in a module is probably a very bad idea.
On my server this problem never occurred, though I am using MPM worker. It seems like this issue only occurs under very special circumstances, thus finding the real cause might be very difficult.
- Sebastian
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ suPHP mailing list suPHP@lists.marsching.biz http://lists.marsching.com/mailman/listinfo/suphp
