httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: signals under worker mpm?
Date Thu, 02 Dec 2004 00:34:54 GMT
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
> ->
> 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.


> 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


Thanks Jeff for the detailed explanation!

So here is the proposed addition to the
doc, based on your input, Jeff:

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 

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.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message