Re^9: Print inside SIGNALS

Replies are listed 'Best First'.
Re^10: Print inside SIGNALS by haukex (Archbishop) on Jul 18, 2018 at 14:40 UTC
Don't kill the program (e.g. by sending SIGINT to the program) and then complain that the rest of the program (e.g. the signal handler) doesn't run. I didn't. `$ perl -e 'sleep 10;print"World\n"' \| perl -e '$x=time; $SIG{ALRM}=sub{print"Hello ";$y=time}; alarm 2; $z=<>; print $z,$y-$x," ",time-$x,"\n"' Hello World 2 10` [download] On my system, all of the above output does not happen until after 10 seconds. See above.	[reply] [d/l]
Re^11: Print inside SIGNALS by Veltro (Hermit) on Jul 19, 2018 at 11:05 UTC
Funny discussion. But I think both of you are correct. When blocking the program with `<>`, is the alarm signal block executed when I send SIGINT? On Unix/Linux: In case waited long enough for the alarm timeout to happen: Yes, always. So why is it not printed? A buffering issue? Yes and no. Yes and no? Yes, data may be stuck in the buffer when using STDOUT (e.g. it did not have a "\n" when that was the flush condition). But that is not the reason why it is not printed. Sigh..., so why is it not printed then? Because the program received a SIGINT and terminated because the program does not have a handler. Remind that the intention of SIGINT is to provide a mechanism for an orderly, graceful shutdown. But the program doesn't have that so it has ended prematurely and the buffer is not flushed at normal program end. But why is the line ending with a '\n' printed then after sending the SIGINT? Because the line was already transferred to the operating system buffer. But that buffer was only flushed after the blocking `<>` was terminated. This is how I think it works and why I think you are both right. However not entirely explained correctly maybe.	[reply] [d/l] [select]
Re^12: Print inside SIGNALS by haukex (Archbishop) on Jul 19, 2018 at 17:34 UTC
Sorry, but no, the central point of this discussion has nothing to do with SIGINT, and even whether something is output to STDOUT is a secondary issue. Above, ikegami said that the SIGALRM handler would fire after and not during `<>`, which I doubted, tested, and showed that it's not how it behaves - at least on my system, in case that makes a difference, hence my oneliners and questions above. The claim that I must've sent the SIGINT before the SIGALRM handler could fire is nonsense.	[reply] [d/l]
Re^13: Print inside SIGNALS by Veltro (Hermit) on Jul 19, 2018 at 20:09 UTC
Re^14: Print inside SIGNALS by haukex (Archbishop) on Jul 19, 2018 at 21:17 UTC
Some notes below your chosen depth have not been shown here
Re^12: Print inside SIGNALS by ikegami (Patriarch) on Jul 20, 2018 at 18:44 UTC
Yes, data may be stuck in the buffer when using STDOUT No, not in the `<>` case. The signal handler is only called between Perl ops, so it can't be called until `<>` returns, so it hadn't been called by the the time the process was killed. Adding `\n` wouldn't make a difference.	[reply] [d/l] [select]
Re^13: Print inside SIGNALS (updated) by haukex (Archbishop) on Jul 20, 2018 at 19:25 UTC
Re^14: Print inside SIGNALS by kcott (Archbishop) on Jul 20, 2018 at 20:44 UTC
Some notes below your chosen depth have not been shown here
Re^14: Print inside SIGNALS by pryrt (Abbot) on Jul 20, 2018 at 19:52 UTC
Some notes below your chosen depth have not been shown here
Re^14: Print inside SIGNALS by Veltro (Hermit) on Jul 20, 2018 at 20:00 UTC
Some notes below your chosen depth have not been shown here
Re^11: Print inside SIGNALS by ikegami (Patriarch) on Jul 20, 2018 at 18:43 UTC
I didn't. Don't lie. Your own output showed you used Ctrl-C. all of the above output does not happen until after 10 seconds This was already explained.	[reply]
Re^12: Print inside SIGNALS by haukex (Archbishop) on Jul 20, 2018 at 18:58 UTC
Don't lie. Your own output showed you used Ctrl-C. You said that I shouldn't complain that the signal handler didn't run, and I said "I didn't", because as far as I could tell the signal handler did run. Update: Improved wording. Also, please see my reply here.	[reply]