On Mon, 29 Nov 2004 22:36:01 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Jeff Trawick wrote:
>
>
> > On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman <[EMAIL PROTECTED]> 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.
