Re: Print inside SIGNALS
by Corion (Patriarch) on Jul 16, 2018 at 13:50 UTC
|
alarm 2;
$SIG{ALRM} = \&Finish;
sleep 30;
sub Finish { print "Timeout reached"; }
But also see perlipc on signals and how they (badly) interact with filehandles. | [reply] [d/l] |
|
Thank everybody...
My actual perl program is huge to post it here. It does not use threads but it execute many external commands.
The Signal works and the Finish sub is executed.... it deletes temp files, close FHs, etc... everything works BUT print.. it does not print anything in STDOUT!
If the Finish sub is executed by the program itself (not via ALARM), then it prints to STDOUT normally..
I know that you are not magicians and that without the full code you cannot be accurate, but i would appreciate any clue or suggestion you may provide, please...
| [reply] |
|
| [reply] [d/l] [select] |
|
$| = 1;
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] [d/l] |
|
| [reply] |
|
I'm on a Debian box as well, and the behaviour is like this:
- Your original code doesn't print anything because the program finishes before the timer rings. That's quite normal.
- With Corion's example, I get the print - but not the full sleep time, the code immediately resumes after the alarm. I didn't know that, but the alarm documentation gives a hint: It is usually a mistake to intermix "alarm" and "sleep" calls, because "sleep" may be internally implemented on your system with "alarm".
If your C library's print function isn't re-entrant (many aren't), then there's always a chance that weird things happen when the signal goes off while your code is printing something.
| [reply] |
|
|
|
| [reply] |
|
it seems ALARM only affects user level calls..
Not at all. As Corion's program demonstrates, system calls are clearly interrupted.
The signal will only be handled between Perl ops, so a long running op (regex match or XS function call) could delay the handling of the signal.
| [reply] |
|
| [reply] |
|
|
|
|
Re: Print inside SIGNALS
by tybalt89 (Monsignor) on Jul 16, 2018 at 14:04 UTC
|
perl -e 'alarm 3;$SIG{ALRM}=sub{print "Timeout reached\n"}; sleep 10'
works for me on my ArchLinux system.
Note you didn't have a newline on your print, maybe you just missed the output
because it wasn't on a separate line?
| [reply] [d/l] |
Re: Print inside SIGNALS
by pedrete (Sexton) on Jul 16, 2018 at 19:46 UTC
|
alarm 2;
$SIG{ALRM} = \&Finish;
while (1==1){};
sub Finish { print "Timeout reached"; }
BUT... This code works... and after 2 seconds, the program dies...
alarm 2;
$SIG{ALRM} = \&Finish;
while (1==1){};
sub Finish { die; }
So something happens with print... | [reply] [d/l] [select] |
|
I can replicate that the first snippet doesn't seem to output anything. However, it seems that the signal does get triggered, it just has something to do with buffering, as the following two examples work. Are you really just doing print "Timeout reached"; in your original code, without the newline or anything else that would cause the output to get flushed? See also Suffering from Buffering.
$ perl -wMstrict -e 'alarm 2; $SIG{ALRM}=sub{
print "Timeout reached" }; while(){}'
^C
$ perl -wMstrict -e 'alarm 2; $SIG{ALRM}=sub{
print "Timeout reached\n" }; while(){}'
Timeout reached
$ perl -wMstrict -e '$|++; alarm 2; $SIG{ALRM}=sub{
print "Timeout reached" }; while(){}'
Timeout reached
Elsewhere in this thread you said:
My actual perl program is huge to post it here. It does not use threads but it execute many external commands.
Well, the trick is to reduce the actual code down to an SSCCE. Delete some code from your program, if the problem persists, that code can stay deleted, but if the problem goes away, then put that code back in. Repeat this over and over until your code is a 10 to 20 line program that demonstrates the issue. Not only will this help you in narrowing down the problem, it'll give us a way to reproduce the actual issue ourselves.
Other than the above buffering issue, I wouldn't exclude the possibility that one of the external programs is the culprit, or something else you're doing in your "huge" program. For example, perhaps something questionable is happening to STDOUT. | [reply] [d/l] [select] |
|
| [reply] [d/l] [select] |
|
|
|
| [reply] |
|
This is not so special. If you print to a terminal, you might note that this code does work, in the sense that the output appears after two seconds:
alarm 2;
$SIG{ALRM} = \&Finish;
while (1==1){};
sub Finish { print "Timeout reached\n"; }
After that, the endless loop continues.
The only difference is the line feed: STDOUT is typically line buffered if output is to the terminal. So, you just don't see the output.
For output to a file or socket, you might want to set $| to a true value.
| [reply] [d/l] |
A reply falls below the community's threshold of quality. You may see it by logging in. |