in reply to Re^4: Print inside SIGNALS
in thread Print inside SIGNALS

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.

Replies are listed 'Best First'.
Re^6: Print inside SIGNALS
by haukex (Archbishop) on Jul 17, 2018 at 11:50 UTC
    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.

    At least on my machine (Linux), it seems to be the same buffering issue...

    $ perl -wMstrict -e 'alarm 2; $SIG{ALRM}=sub{
    print "Timeout reached" };<>'
^C
$ perl -wMstrict -e 'alarm 2; $SIG{ALRM}=sub{
    print "Timeout reached\n" };<>'
Timeout reached
^C
$ perl -wMstrict -e 'alarm 2; $SIG{ALRM}=sub{
    print STDERR "Timeout reached" };<>'
Timeout reached^C

    [download]
[reply]
[d/l]
[select]

      No, "it didn't work" for you because you killed the program before the signal handler was called.

[reply]
        No, "it didn't work" for you because you killed the program before the signal handler was called.

        Have you tried the one-liners yourself? (I ran them on Ubuntu Linux, in case that makes a difference.)

        Are you saying you are observing different behavior than I am? If so, what is that behavior?

        If you're saying it's not a buffering issue, what do you think is causing the different behavior of the first two of my one-liners above?

[reply]

In Section Seekers of Perl Wisdom