You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2004/11/29 19:24:29 UTC
signals under worker mpm?
Is there some doc explaining the usage of signal handlers under different
mpms? 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,
simple grepping doesn't come up with anything useful, so if someone who
understands those issues could follow up, that would be great. Thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Stas Bekman <st...@stason.org>.
Cliff Woolley wrote:
> On Mon, 29 Nov 2004, Stas Bekman wrote:
>
>
>>nuke it?
>>
>>So this is incorrect?
>>
>> - The MPM does not set a SIGALRM handler, user code may use SIGALRM.
>
>
> It can use it if it knows what it's doing.
What do you mean?
> A mod_perl module that's
> expected to work on any MPM (which is I'm assuming what you're talking
> about) is not going to fall into the category of "knows what it's doing"
> if it tries to use signals. :-)
It's the case with any other mod_*, not only mod_perl.
What the alternative solution for the widely used alarm() technique?
I'd expect to have a documented API, regarding signals in Apache 2.x
* No signals are to be used in user code
* Certain signals (please list which) can be used in all mpms
* Certain signals (please list which) can be used only in certain mpms.
The current situation of guess what works and what will continue to work
tomorrow approach sucks.
Let's polish this issue and I'll make sure it's properly documented.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Cliff Woolley wrote:
> On Mon, 29 Nov 2004, Stas Bekman wrote:
>
>
>>nuke it?
>>
>>So this is incorrect?
>>
>> - The MPM does not set a SIGALRM handler, user code may use SIGALRM.
>
>
> It can use it if it knows what it's doing.
Too much rope Cliff, too much rope. :-)
> A mod_perl module that's
> expected to work on any MPM (which is I'm assuming what you're talking
> about) is not going to fall into the category of "knows what it's doing"
> if it tries to use signals. :-)
>
Re: signals under worker mpm?
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 29 Nov 2004, Stas Bekman wrote:
> nuke it?
>
> So this is incorrect?
>
> - The MPM does not set a SIGALRM handler, user code may use SIGALRM.
It can use it if it knows what it's doing. A mod_perl module that's
expected to work on any MPM (which is I'm assuming what you're talking
about) is not going to fall into the category of "knows what it's doing"
if it tries to use signals. :-)
Re: signals under worker mpm?
Posted by Stas Bekman <st...@stason.org>.
Cliff Woolley wrote:
> On Mon, 29 Nov 2004, Stas Bekman wrote:
>
>
>>./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.
>
>
> That's an ancient comment that dates back to Apache 1.3 and no longer
> applies to anything. BUFF no longer exists.
nuke it?
So this is incorrect?
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 29 Nov 2004, Stas Bekman wrote:
> ./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.
That's an ancient comment that dates back to Apache 1.3 and no longer
applies to anything. BUFF no longer exists.
Re: signals under worker mpm?
Posted by Stas Bekman <st...@stason.org>.
Thanks Jeff and Andy, here is the updated version:
<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). 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.
<OUT>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, 01 Dec 2004 19:34:54 -0500, Stas Bekman <st...@stason.org> 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
Re: signals under worker mpm?
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, 02 Dec 2004 07:41:58 +0000, Andy Armstrong <an...@apache.org> wrote:
> Stas Bekman wrote:
> [snip]
> > 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.
>
> Is it actually worth mentioning that? It seems to invite people who
> don't really know what they're doing around threads to get in too deep.
> I would imagine that anyone who's competent to do that would have
> already got the message from the previous text :)
Agreed, not something we want to mention in the docs. It begs more
and more details which would not be forthcoming ;)
Re: signals under worker mpm?
Posted by Andy Armstrong <an...@apache.org>.
Stas Bekman wrote:
[snip]
> 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.
Is it actually worth mentioning that? It seems to invite people who
don't really know what they're doing around threads to get in too deep.
I would imagine that anyone who's competent to do that would have
already got the message from the previous text :)
Re: signals under worker mpm?
Posted by Stas Bekman <st...@stason.org>.
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
>
> http://httpd.apache.org/docs-2.0/developer/
> -> http://httpd.apache.org/docs-2.0/developer/thread_safety.html
>
> 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.
Agreed.
> 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
Understood.
Thanks Jeff for the detailed explanation!
So here is the proposed addition to the
http://httpd.apache.org/docs-2.0/developer/thread_safety.html
doc, based on your input, Jeff:
<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.
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.
<OUT>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, 29 Nov 2004 22:36:01 -0500, Stas Bekman <st...@stason.org> wrote:
> Jeff Trawick wrote:
>
>
> > On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman <st...@stason.org> wrote:
> >
> >>Jeff Trawick wrote:
> >>
> >>
> >>>How is SIGALRM used specifically?
> >>
> >>e.g.:
> >> eval {
> >> POSIX::sigaction(SIGALRM,
> >> POSIX::SigAction->new(sub { die "alarm" }))
> >> or die "Error setting SIGALRM handler: $!\n";
> >> alarm 2;
> >> potentially_long_running_process()
> >> alarm 0;
> >> };
> >> do_something() if $@ && $@ =~ /alarm/;
> >
> >
> > no, can't do that, unless you're the only thread in the process that
> > does anything like that since
> >
> > 1) any other code in the process can wipe out your SIGALRM handler
> > 2) only one "alarm" per process
>
> Thanks Jeff for the explanations.
>
> So it's a 100% no go with threads. But I understand that it should work
> just fine with prefork (and it does so far). so I have the following
> questions:
>
> 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
http://httpd.apache.org/docs-2.0/developer/
-> http://httpd.apache.org/docs-2.0/developer/thread_safety.html
That already points out some generic thread safety information. The
inappropriateness of the alarm()/SIGALRM idiom is another piece of
such information.
> 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
> 3) in the particular case of threads, what's the alternative approach to
> the SIGALARM technique to trap long running/potentially run-away code
> (e.g. IO). So we can offer something to the users migrating their code
> from 1.3.x.
explicit:
I/O timeout handling is accomplished by modifying the I/O logic for
select/poll usage (or if you use APR I/O then set timeouts on the apr
pipes or sockets)
CPU timeout handling is accomplished by modifying the computation
logic to explicitly check for the timeout at intervals
magic:
This could *possibly* be done with 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
probably out of reach of most folks.
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.
Re: signals under worker mpm?
Posted by Stas Bekman <st...@stason.org>.
Jeff Trawick wrote:
> On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman <st...@stason.org> wrote:
>
>>Jeff Trawick wrote:
>>
>>
>>>How is SIGALRM used specifically?
>>
>>e.g.:
>> eval {
>> POSIX::sigaction(SIGALRM,
>> POSIX::SigAction->new(sub { die "alarm" }))
>> or die "Error setting SIGALRM handler: $!\n";
>> alarm 2;
>> potentially_long_running_process()
>> alarm 0;
>> };
>> do_something() if $@ && $@ =~ /alarm/;
>
>
> no, can't do that, unless you're the only thread in the process that
> does anything like that since
>
> 1) any other code in the process can wipe out your SIGALRM handler
> 2) only one "alarm" per process
Thanks Jeff for the explanations.
So it's a 100% no go with threads. But I understand that it should work
just fine with prefork (and it does so far). so I have the following
questions:
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?
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)
3) in the particular case of threads, what's the alternative approach to
the SIGALARM technique to trap long running/potentially run-away code
(e.g. IO). So we can offer something to the users migrating their code
from 1.3.x.
>>>Is there some thread-aware service which works sort of like the thread-unaware alarm()
>>>call which will send SIGALRM to a specific thread?
>>
>>Nope. but if the signal is sent by the same thread that catches it, it's
>>still not guaranteed that it'll get it?
>
>
> the SIGALRM signal sent due to a call to alarm() is sent by the
> kernel; no guarantee which thread will get it, unless there is only
> one thread which doesn't have SIGALRM blocked
Got it. Thanks Jeff.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman <st...@stason.org> wrote:
> Jeff Trawick wrote:
>
> > How is SIGALRM used specifically?
>
> e.g.:
> eval {
> POSIX::sigaction(SIGALRM,
> POSIX::SigAction->new(sub { die "alarm" }))
> or die "Error setting SIGALRM handler: $!\n";
> alarm 2;
> potentially_long_running_process()
> alarm 0;
> };
> do_something() if $@ && $@ =~ /alarm/;
no, can't do that, unless you're the only thread in the process that
does anything like that since
1) any other code in the process can wipe out your SIGALRM handler
2) only one "alarm" per process
> > Is there some thread-aware service which works sort of like the thread-unaware alarm()
> > call which will send SIGALRM to a specific thread?
>
> Nope. but if the signal is sent by the same thread that catches it, it's
> still not guaranteed that it'll get it?
the SIGALRM signal sent due to a call to alarm() is sent by the
kernel; no guarantee which thread will get it, unless there is only
one thread which doesn't have SIGALRM blocked
Re: signals under worker mpm?
Posted by Stas Bekman <st...@stason.org>.
Jeff Trawick wrote:
> How is SIGALRM used specifically?
e.g.:
eval {
POSIX::sigaction(SIGALRM,
POSIX::SigAction->new(sub { die "alarm" }))
or die "Error setting SIGALRM handler: $!\n";
alarm 2;
potentially_long_running_process()
alarm 0;
};
do_something() if $@ && $@ =~ /alarm/;
> Is there some thread-aware service which works sort of like the thread-unaware alarm()
> call which will send SIGALRM to a specific thread?
Nope. but if the signal is sent by the same thread that catches it, it's
still not guaranteed that it'll get it?
> 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
Understood. it's true even if the signal is sent by the same thread that
catches it? See the example above for the test case.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, 29 Nov 2004 16:16:09 -0500, Stas Bekman <st...@stason.org> wrote:
> Jeff Trawick wrote:
> > On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <st...@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
Re: signals under worker mpm?
Posted by Stas Bekman <st...@stason.org>.
Bill Stoddard wrote:
> Stas Bekman wrote:
>
>> Jeff Trawick wrote:
>>
>>> On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <st...@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.
>
>
> Then god help us all. I'm constantly reminded in my day to day work that
> there are really very few people 'out there' who really appreciate the
> nuances of threaded programming on Unix. Bleh.
Even with POSIX signal handlers?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Stas Bekman wrote:
> Jeff Trawick wrote:
>
>> On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <st...@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.
Then god help us all. I'm constantly reminded in my day to day work that there are really very few people 'out
there' who really appreciate the nuances of threaded programming on Unix. Bleh.
Bill
Re: signals under worker mpm?
Posted by Stas Bekman <st...@stason.org>.
Jeff Trawick wrote:
> On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <st...@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.
>>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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: signals under worker mpm?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <st...@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 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 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?
*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