in reply to Re^13: Print inside SIGNALS (updated)
in thread Print inside SIGNALS

As a third party: I was debating whether to interject, but this gave me an opening. I have seen what looks like (to me) both behaviors -- I added in some extra information (perl version, timestamp) when prints happen, and ran some one-liners similar to Re^6: Print inside SIGNALS.

In Windows, I see what I think ikegami has described: no matter what, the SIG{ALRM} isn't firing, presumably because the <> blocks it...

C:\usr\local\share\PassThru\perl>perl -wMstrict -e "sub p { local $, = + qq{: }; print $], scalar(localtime), @_ }; alarm 2; $SIG{ALRM}=sub{p + qq{Timeout reached\n} }; p qq{before I hit enter\n}; <>; p qq{after +I hit enter\n}" 5.026002: Fri Jul 20 12:20:40 2018: before I hit enter never saw the timeout, so hit enter 5.026002: Fri Jul 20 12:20:57 2018: after I hit enter C:\usr\local\share\PassThru\perl>perl -wMstrict -e "sub p { local $, = + qq{: }; print $], scalar(localtime), @_ }; alarm 2; $SIG{ALRM}=sub{p + qq{Timeout reached } }; p qq{before I hit enter\n}; <>; p qq{after +I hit enter\n}" 5.026002: Fri Jul 20 12:21:05 2018: before I hit enter never saw the timeout, so hit enter 5.026002: Fri Jul 20 12:21:21 2018: after I hit enter

But in linux, with the \n, the "timeout reached" prints after the 2 seconds, then when I hit ENTER, it prints what comes after the <>; but if I don't have \n, I can count to about 15, type, and hit ENTER, and then it will print both the "timeout reached" and the "after" messages on the same line, showing that the events themselves happened about 30sec apart.

pryrt@pryrtdebian:~$ perl -wMstrict -e 'sub p { local $, = qq{: }; pri +nt $], scalar(localtime), @_ }; alarm 2; $SIG{ALRM}=sub{p qq{Timeout +reached\n} }; p qq{before I hit enter\n}; <>; p qq{after I hit enter\ +n}' 5.020003: Fri Jul 20 12:23:50 2018: before I hit enter 5.020003: Fri Jul 20 12:23:52 2018: Timeout reached after two seconds, that popped up, then I typed this slowly, with ENTE +R 5.020003: Fri Jul 20 12:24:12 2018: after I hit enter pryrt@pryrtdebian:~$ perl -wMstrict -e 'sub p { local $, = qq{: }; pri +nt $], scalar(localtime), @_ }; alarm 2; $SIG{ALRM}=sub{p qq{Timeout +reached } }; p qq{before I hit enter\n}; <>; p qq{after I hit enter\ +n}' 5.020003: Fri Jul 20 12:24:22 2018: before I hit enter counted to about 15, never saw timeout, typed this, hit ENTER 5.020003: Fri Jul 20 12:24:24 2018: Timeout reached 5.020003: Fri Jul + 20 12:24:57 2018: after I hit enter

To me, it really looks like under linux, the <> is not blocking the SIG{ALRM} from firing, and that the \n is showing it's buffering which is causing the delay when there's no \n. I cannot explain what I saw, otherwise.

armed with haukex's newest oneliner, I see

__WINDOWS__ C:\usr\local\share\PassThru\perl>perl -wMstrict -le "$a=time;$SIG{ALRM +}=sub{$b=time};alarm 2;<>;print $b-$a" Use of uninitialized value $b in subtraction (-) at -e line 1, <> line + 1. -1532115378 __LINUX__ pryrt@pryrtdebian:~$ perl -wMstrict -le '$a=time;$SIG{ALRM}=sub{$b=tim +e};alarm 2;<>;print $b-$a' 2

once again, I see that on Windows, it appears that <> has prevented the alarm from firing; but in linux, it did not. In windows, I added in a second sleep after the first print, and did the print again:

__WINDOWS__ C:\usr\local\share\PassThru\perl>perl -wMstrict -le "$a=time;$SIG{ALRM +}=sub{$b=time};alarm 2;<>;print $b-$a;sleep 5; print $b-$a" Use of uninitialized value $b in subtraction (-) at -e line 1, <> line + 1. -1532115756 10

between the first and second print, after hitting enter for the <>, then there is enough time for the alarm to run. Doing the same in linux, it seems to me that ALARM triggered the once, during the initial time before <> was completed by my hitting enter, so I don't think <> was blocking it:

__LINUX__ peter@peterjonesdebian:~$ perl -wMstrict -le '$a=time;$SIG{ALRM}=sub{$ +b=time};alarm 2;<>;print $b-$a;sleep 5;print $b-$a' 2 2

edit: joined lines that were accidentally separated when I copied from windows cmd.exe window

Replies are listed 'Best First'.
Re^15: Print inside SIGNALS
by haukex (Archbishop) on Jul 20, 2018 at 20:28 UTC

    Thank you very much for your reply! I had a chance to test on Windows earlier today, and also just tested all your examples as well, Windows and Linux. It really does seem that <> doesn't appear to be interruptible by signal handlers there, even if I forcibly close STDIN (this works to abort <> on Linux). pedrete said in the root node "Linux Debian", which is why I had left Windows out of my considerations (and didn't even test there initially) and only talked about Linux.