httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: signals under worker mpm?
Date Mon, 29 Nov 2004 22:03:49 GMT
On Mon, 29 Nov 2004 16:16:09 -0500, Stas Bekman <stas@stason.org> wrote:
> Jeff Trawick wrote:
> > On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <stas@stason.org> 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.

How is SIGALRM used specifically?  Is there some thread-aware service
which works sort of like the thread-unaware alarm() call which will
send SIGALRM to a specific thread?

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

SIGALRM is an asynchronous signal which can be delivered on any thread
that does not have the signal specifically blocked; if the user code
is just expecting their operation on the current thread to be
interrupted when the SIGALRM signal is generated, &deity; help them;
potentially some thread-aware code is sending SIGALRM to a specific
thread; it would be helpful to understand the testcase better

> > *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.

unclear whether or not that is completely true

>         But the preferred method of handling timeouts is to use the
>         timeouts provided by the BUFF abstraction.

time to replace that comment with something more generic

Mime
View raw message