|
Re^3: Print inside SIGNALS
by haj (Vicar) on Jul 16, 2018 at 14:19 UTC
|
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]
[d/l] |
|
|
Thanks for the correction! The rule "don't print in signal handling" stuck with me for too long, I should have checked this.
| [reply] |
Re^3: Print inside SIGNALS
by jeffenstein (Hermit) on Jul 16, 2018 at 14:26 UTC
|
Are you using threads in your script? From the threads documentation, signals in threads are not real signals and won't interrupt a blocked system call.
| [reply] |
Re^3: Print inside SIGNALS
by ikegami (Patriarch) on Jul 16, 2018 at 14:24 UTC
|
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] |
Re^3: Print inside SIGNALS
by ikegami (Patriarch) on Jul 16, 2018 at 14:04 UTC
|
| [reply] |
|
|
alarm 2;
$SIG{ALRM} = \&Finish;
my $a=<>;
sub Finish { print "Timeout reached"; }
This code does not work either...
alarm 2;
$SIG{ALRM} = \&Finish;
while (1==1){};
sub Finish { print "Timeout reached"; }
So i guess many calls are not interrumptibles... am i right>? | [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
First snippet: <> can't be interrupted because there's no way to check <> for errors. However, the signal handler does get called once it returns.
Second snippet: There's nothing to interrupt here, so the signal handler gets called immediately. However, since the program has no way of terminating the program cleanly, the message will never leave STDOUT's buffer to the underlying file system handle.
| [reply]
[d/l]
[select] |
|
|
|
|
|
