Jeff Trawick wrote:
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:

Is there some doc explaining the usage of signal handlers under different
mpms?


No, although I would suggest the following ;)

/* @tip Don't use signals in your own modules.  Apache makes no effort to
 * support modules which use signals.  Module behavior which is dependent
 * on signals can be expected to vary between MPMs or platforms.
 */

I don't use, but users do. And SIGALRM is widely used to technique to trap a runaway operation, so we aren't talking about signals in general, but to start with with a few certain ones.


I get SIGALRM working fine under prefork mpm, but not under worker.
I assume that it traps the signal before the user code's handler runs,


child_main() calls apr_setup_signal_thread(), which ignores all
signals.  I suspect this is what "breaks" SIGALRM for you with worker
MPM.  Try commenting out the call to apr_setup_signal_thread().

If I comment it the behavior is completely broken (the thread just silently dies)


If a module doesn't completely isolate its signal use from the MPM, it
may be hard for the module to operate predictably, or for Apache to
make changes to fix its own problems.  What thread are you using to
handle the SIGALRM?  Why not create your own thread and have it sit in
sigwait() for SIGALRM?

again we are talking about the normal worker thread, where a user runs some code first setting SIGALRM.


*don't rely on MPM-created threads to have a particular signal mask
*don't use MPM-created threads to run handlers or otherwise react to signals

Also I've found:

./include/ap_mpm.h
    unix/posix notes:
    - The MPM does not set a SIGALRM handler, user code may use SIGALRM.
        But the preferred method of handling timeouts is to use the
        timeouts provided by the BUFF abstraction.

--
__________________________________________________________________
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

Reply via email to