https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6253
--- Comment #17 from Mark Martinec <[email protected]> 2009-12-17 11:35:52 UTC --- > One question. The previous code had: > - alarm(2); # mercifully grant two additional seconds > Do you know why the 2 seconds was added because I don't see this in the > revised > version? The new code still has it, you probably didn't look closely enough. It's a bit of a hack, but helps the outer spamd complete the transaction with a spamc client when mail checking is aborted due to a time limit. > Other than that, I don't have a test problem before so I'll vote +1 to apply > based on a logic review. The core of a problem on Solaris was that somehow the loop in the test program t/timeout.t in mysleep() could not be interrupted by an alarm signal. Replacing sleep with select helped to avoid the issue. Mixing alarm with sleep is unspecified anyway, so anything could happen, the select should no longer have a problem with that regardless of implementation. While troubleshooting, it also turned out that Time::HiRes::alarm always returned 0 as remaining time (which is allowed, but unusual), so while at it, I also fixed that issue. The Timeout.pm now no longer relies on alarm() returning remaining time, at least in cases of nested timed runs under control of this module. This fix made the patch larger. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
