Hello, Stas Stas Bekman wrote:
alarm(300) is an Apache alarm. Can you see the perl's alarm calls earlier in the trace? since you tried alarm 1, grep for alarm(1).
[EMAIL PROTECTED] tauction]$ grep -P 'alarm' <strace.log alarm(0) = 0 alarm(300) = 0 alarm(300) = 300 alarm(0) = 300 alarm(1) = 0 alarm(300) = 0 alarm(0) = 300 alarm(300) = 0
seems it is here
I think what happens is that perl sets the alarm, but then Apache resets it again to its own value and its own sighandler. Even though it may restore the perl sighandle at the end it's happening too late.
So i'd try:
1)
You could try to lower Apache's IO timeout for this call. I can't see it documented (defined in Server.xs) but you can read/write server timeout values:
my $timeout_secs = 1; my $orig_timeout = $r->server->timeout($timeout_secs); $apr->param; # no perl alarm is now needed $r->server->timeout($orig_timeout_secs);
yep, that closes the connection after $timeout_secs and looks to me like the right solution.
However, If I try to stop apache it exits with 'Segmentation fault' (in case a timeout occured),
seems due to the fact that the perl code haven't had a chance to clean up. Can I trap this timeout ?
2) I'm not sure this will work, since read will probably set the alarm after kill_timeout, so it won't accomplish that affect.
$r->kill_timeout; ... alarm eval here with $apr->param call ... $r->reset_timeout; http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_reset_timeout
that doesn't work
3) Try Sys::Signal to set the perl alarm. I don't think though it'll give you the solution, since it was written to have the C level sighandlers restored after perl's sighandler was called. And recent Apache versions are supposed to work well with plain perl sighandlers.
it doesn't compile for me :((
Thanks
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
