On Wed, 01 Dec 2004 19:34:54 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
> <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. I'd replace the last sentence with For example, Apache 1.3 on Unix made blocking I/O calls and relied on the parent process to send the SIGALRM signal to break it out of the I/O after a timeout expired. With Apache 2.0, APR support for timeouts on I/O operations is used so that signals or other thread-unsafe mechanisms are not necessary. > 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. as mentioned elsewhere, this is probably asking for trouble
