From das@decisionsoft.com

In perl-5.8.0-55 (and others likely), when I do a perl program​:

sleep;
exit; # or exit(0);

then give a SIGALRM to to the process, I always get the exit code of 14
(from the following c program)​:

#include <stdlib.h>
#include <stdio.h>

int main() {
  int d = system("/testscript.pl");
  printf("%s%d\n","Exit code ", d);
}

I think this is a bug in perl.
--
Doug Sibley <das@​decisionsoft.com>

From @schwern

On Thu, Oct 09, 2003 at 05​:23​:58PM -0000, Doug Sibley wrote​:

In perl-5.8.0-55 (and others likely), when I do a perl program​:

5.8.0-55 is not a version number used by Perl. It sounds like some
number assigned by your operating system vendor. Is this from a Redhat
package?

sleep;
exit; # or exit(0);

then give a SIGALRM to to the process, I always get the exit code of 14
(from the following c program)​:

I can repeat this with 5.6.0 and 5.8.0 on OS X.

I think this is a bug in perl.

Doesn't seem like one to me. The program was killed by a SIGALRM and
exited abnormally. Your exit(0) is never reached.

perlipc states that Perl "does the default thing" to handle a signal if
you don't tell it otherwise. The OS X (ie. BSD) signals(3) man page states
that the default action for SIGALRM is to terminate the process.

--
Michael G Schwern schwern@​pobox.com http​://www.pobox.com/~schwern/
I do have a cause though. It is obscenity. I'm for it.
  -- Tom Lehrer "Smut"

From das@decisionsoft.com

http​://www.perl.com/doc/manual/html/pod/perlfunc/sleep.html

says "May be interrupted if the process receives a signal such as
SIGALRM" (as do the O'Reilly series of perl books) which led me to
believe that I could sleep until I sent a SIGALRM at which point the
process would continue.

You may wish to update either the behavior or comments of the sleep
function.

- Doug

On Sat, 2003-10-11 at 09​:20, Michael G Schwern wrote​:

Doesn't seem like one to me. The program was killed by a SIGALRM and
exited abnormally. Your exit(0) is never reached.

perlipc states that Perl "does the default thing" to handle a signal if
you don't tell it otherwise. The OS X (ie. BSD) signals(3) man page states
that the default action for SIGALRM is to terminate the process.
--
Doug Sibley <das@​decisionsoft.com>

From @schwern

On Mon, Oct 13, 2003 at 09​:41​:08AM +0100, Doug Sibley wrote​:

http​://www.perl.com/doc/manual/html/pod/perlfunc/sleep.html

says "May be interrupted if the process receives a signal such as
SIGALRM" (as do the O'Reilly series of perl books) which led me to
believe that I could sleep until I sent a SIGALRM at which point the
process would continue.

You may wish to update either the behavior or comments of the sleep
function.

Hmm. It should probably show an example of the usual idiom.

--- pod/perlfunc.pod 2003/10/13 12​:11​:23 1.1
+++ pod/perlfunc.pod 2003/10/13 12​:12​:07
@​@​ -4576,10 +4576,18 @​@​
=item sleep

Causes the script to sleep for EXPR seconds, or forever if no EXPR.
+Returns the number of seconds actually slept.
+
May be interrupted if the process receives a signal such as C<SIGALRM>.
-Returns the number of seconds actually slept. You probably cannot
-mix C<alarm> and C<sleep> calls, because C<sleep> is often implemented
-using C<alarm>.
+
+ eval {
+ local $SIG{ALARM} = sub { die "Alarm!\n" };
+ sleep;
+ };
+ die $@​ unless $@​ eq "Alarm!\n";
+
+You probably cannot mix C<alarm> and C<sleep> calls, because C<sleep>
+is often implemented using C<alarm>.

On some older systems, it may sleep up to a full second less than what
you requested, depending on how it counts seconds. Most modern systems

--
Michael G Schwern schwern@​pobox.com http​://www.pobox.com/~schwern/
Cuius rei demonstrationem mirabilem sane detexi hanc subscriptis
exiguitas non caperet.

From whatever@davidnicol.com

I was a little startled by this too, I thought I had been using
sleep(0) in C to sleep until receiving an ALRM for years, and that
this idiom would fall through to perl. Apparently you
need to set up a handler, even a null handler would work, to
catch the signal instead of the default handler, which
appears to print out "Alarm clock" and crap out. Experiments
and results below​:

[david@​plaza david]$ perl -le 'sleep 0; print "slept"' &
slept
[1] 1618
[1] Done perl -le 'sleep 0; print "slept"'
[david@​plaza david]$ perl -le 'sleep 9990; print "slept"' &
[1] 1622
[david@​plaza david]$ kill -ALRM 1622
[david@​plaza david]$
[1]+ Alarm clock perl -le 'sleep 9990; print "slept"'
[david@​plaza david]$ perl -le '$SIG{ALRM} = sub{ print "alarmed" } ;
sleep 9990;
print "slept"' &
[1] 1623
[david@​plaza david]$ kill -ALRM 1623
[david@​plaza david]$ alarmed
slept
[david@​plaza david]$

On Mon, 2003-10-13 at 03​:41, Doug Sibley wrote​:

http​://www.perl.com/doc/manual/html/pod/perlfunc/sleep.html

says "May be interrupted if the process receives a signal such as
SIGALRM" (as do the O'Reilly series of perl books) which led me to
believe that I could sleep until I sent a SIGALRM at which point the
process would continue.

You may wish to update either the behavior or comments of the sleep
function.

- Doug

On Sat, 2003-10-11 at 09​:20, Michael G Schwern wrote​:

Doesn't seem like one to me. The program was killed by a SIGALRM and
exited abnormally. Your exit(0) is never reached.

perlipc states that Perl "does the default thing" to handle a signal if
you don't tell it otherwise. The OS X (ie. BSD) signals(3) man page states
that the default action for SIGALRM is to terminate the process.
--
david nicol
"In your own mind, you are the hoopiest frood. That is all that matters."
  -- Gargoyle Cabbit

p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'

From @smpeters

On Mon Oct 13 11​:06​:18 2003, schwern wrote​:

On Mon, Oct 13, 2003 at 09​:41​:08AM +0100, Doug Sibley wrote​:

http​://www.perl.com/doc/manual/html/pod/perlfunc/sleep.html

says "May be interrupted if the process receives a signal such as
SIGALRM" (as do the O'Reilly series of perl books) which led me to
believe that I could sleep until I sent a SIGALRM at which point the
process would continue.

You may wish to update either the behavior or comments of the sleep
function.

Hmm. It should probably show an example of the usual idiom.

--- pod/perlfunc.pod 2003/10/13 12​:11​:23 1.1
+++ pod/perlfunc.pod 2003/10/13 12​:12​:07
@​@​ -4576,10 +4576,18 @​@​
=item sleep

Causes the script to sleep for EXPR seconds, or forever if no EXPR.
+Returns the number of seconds actually slept.
+
May be interrupted if the process receives a signal such as C<SIGALRM>.
-Returns the number of seconds actually slept. You probably cannot
-mix C<alarm> and C<sleep> calls, because C<sleep> is often implemented
-using C<alarm>.
+
+ eval {
+ local $SIG{ALARM} = sub { die "Alarm!\n" };
+ sleep;
+ };
+ die $@​ unless $@​ eq "Alarm!\n";
+
+You probably cannot mix C<alarm> and C<sleep> calls, because C<sleep>
+is often implemented using C<alarm>.

On some older systems, it may sleep up to a full second less than what
you requested, depending on how it counts seconds. Most modern systems

Thanks! I applied your patch as change #34080. Almost five years
later, but it still applied.

Steve Peters