Jeff Trawick wrote: [...]
1) what would be the best place to document that in the Apache docs (mpm include/ap_mpm.h or should each mpm have it documented separately?
how about at
http://httpd.apache.org/docs-2.0/developer/ -> http://httpd.apache.org/docs-2.0/developer/thread_safety.html
That already points out some generic thread safety information. The inappropriateness of the alarm()/SIGALRM idiom is another piece of such information.
Sounds good, but let's polish here first what we want to add.
2) what's the policy on non-threaded mpms, i.e. which signals are declared usable in the user code (i.e. declare an API so one could rely on it)
We can have a small section on signals in that document to point out that typical signal use is not thread-safe, and that modules which rely on signals may not work portably. A good example would be a module which uses alarm() and happens to work with the prefork MPM on Unix but does not work with any other MPM or platform.
Agreed.
As far as explicitly laying out what sort of signal usage will work in which MPMs: (a) I'm not sure we can do an accurate job without spending a lot of effort, and then we're tied to trying to make whatever we document work forever and ever (b) we wouldn't want to promote such practices anyway
Understood.
Thanks Jeff for the detailed explanation!
So here is the proposed addition to the http://httpd.apache.org/docs-2.0/developer/thread_safety.html doc, based on your input, Jeff:
<IN> ---------------------------------------- Usage of signals outside the httpd core: ----------------------------------------
3rd party Apache 2 modules should avoid using code relying on signals. This is because typical signal use is not thread-safe and modules which
rely on signals may not work portably. Certain signals may still work for non-threaded mpms. For example alarm() can be used under prefork MPM, but it won't work on any other MPM. Moreover Apache can't guarantee that the signals that currently happen to work will continue to do so in the future Apache releases. So use them at your own risk.
It should be possible to rework the code using signals to use an alternative solution, which works under threads. For example if you were using alarm() to trap potentially long running I/O, you can modify the I/O logic for select/poll usage (or if you use APR I/O then set timeouts on the apr pipes or sockets). Apache 2.0 switched from the magic, thread-unsafe mechanism of having the parent send SIGALRM when the child didn't update a timeout field in the scoreboard for a "long time" to the explicit thread-safe mechanism of using select()/poll() on I/O.
CPU timeout handling is another example. It can be accomplished by modifying the computation logic to explicitly check for the timeout at intervals.
Alternatively one could use a manager thread that implements something like a thread-specific alarm(), where a signal handler running on the interrupted thread does siglongjmp() to break out of the interrupted processing, but implementing that sort of service is not trivial. <OUT>
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
