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?
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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
