On Mon, 29 Nov 2004 16:16:09 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote: > 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.
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
