Re: Print inside SIGNALS

Replies are listed 'Best First'.
Re^2: Print inside SIGNALS by pedrete (Sexton) on Jul 16, 2018 at 15:28 UTC
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]
Re^3: Print inside SIGNALS by ikegami (Patriarch) on Jul 16, 2018 at 16:51 UTC
`print` returns false and sets `$!` on failure.	[reply] [d/l] [select]
Re^3: Print inside SIGNALS by shmem (Chancellor) on Jul 17, 2018 at 23:27 UTC
Turn on autoflush (see perlvar): `$\| = 1;` [download] perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'	[reply] [d/l]
Re^2: Print inside SIGNALS by pedrete (Sexton) on Jul 16, 2018 at 13:56 UTC
Thanks Corion... it does not work in my Debian box ... :-( I edit... It works! it seems ALARM only affects user level calls...	[reply]
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]
Re^4: Print inside SIGNALS by ikegami (Patriarch) on Jul 16, 2018 at 14:21 UTC
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. That's not true for two reasons: `print` doesn't use clib. Since Perl 5.8.1, signals are deferred to be handled between Perl ops.	[reply] [d/l]
Re^5: Print inside SIGNALS by haj (Vicar) on Jul 16, 2018 at 14:41 UTC
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
Then something is really messed up with your box. Unless you didn't actually run Corion's program?	[reply]
Re^4: Print inside SIGNALS by pedrete (Sexton) on Jul 16, 2018 at 19:43 UTC
This code does not work... `alarm 2; $SIG{ALRM} = \&Finish; my $a=<>; sub Finish { print "Timeout reached"; }` [download] This code does not work either... `alarm 2; $SIG{ALRM} = \&Finish; while (1==1){}; sub Finish { print "Timeout reached"; }` [download] So i guess many calls are not interrumptibles... am i right>?	[reply] [d/l] [select]
Re^5: Print inside SIGNALS by haukex (Archbishop) on Jul 16, 2018 at 20:20 UTC
Re^5: Print inside SIGNALS by ikegami (Patriarch) on Jul 17, 2018 at 11:22 UTC
Re^6: Print inside SIGNALS by haukex (Archbishop) on Jul 17, 2018 at 11:50 UTC
Some notes below your chosen depth have not been shown here


Syntactic Confectionery Delight
	PerlMonks