httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: signals under worker mpm?
Date Thu, 02 Dec 2004 12:31:48 GMT
On Wed, 01 Dec 2004 19:34:54 -0500, Stas Bekman <> 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

View raw message