Re: Allowing user to abort waitpid

the problem is that waitpid exits (with -1) the moment the Alarm handler is executed

That's not a problem, it's a feature :) If you install a handler for a signal, and the handler gets invoked during interruptible system call (waitpid is interruptible), the system call fails with errno ($! in Perl) set to EINTR.

So you can install a handler for SIGINT, and abort waiting by pressing Control-C instead of 'A'. Then check if $! equals POSIX::EINTR.

If you must use 'A' rather than Control-C, you can use POSIX::Termios to change the interrupt character. Something like that (maybe there is a better way, but it should at least give you some food for thought):

use strict;
use warnings;

use POSIX ();

my $new_interrupt_char = 'A';
my $seconds_to_sleep   = 5;

if ( POSIX::isatty( POSIX::STDIN_FILENO ) ) {

    my $term = POSIX::Termios->new();
    $term->getattr( POSIX::STDIN_FILENO );
    my $old_interrupt_char = $term->getcc( POSIX::VINTR );
    $term->setcc( POSIX::VINTR, ord $new_interrupt_char );
    $term->setattr( POSIX::STDIN_FILENO );
    END {
        # restore the interrupt char to default (Control-C)
        if ( defined $term ) {
            $term->setcc( POSIX::VINTR, $old_interrupt_char );
            $term->setattr( POSIX::STDIN_FILENO );
        }
    }
}

$SIG{INT} = sub {
    print "SIGINT handler called\n";
};

my $slept = sleep $seconds_to_sleep;   # use waitpid instead of sleep
if ( $slept != $seconds_to_sleep and $! == POSIX::EINTR ) {
    print "Sleep was interrupted, slept $slept secs\n";
}
[download]

Comment on Re: Allowing user to abort waitpid Select or Download Code

Replies are listed 'Best First'.
Re^2: Allowing user to abort waitpid by Anonymous Monk on Mar 07, 2016 at 09:18 UTC
Oh, I forgot to add: Control-C (or 'A') will send the signal to your child too. If you install the handler after `fork`, the child will get killed, which, it seems, is what you want? But if you don't want that, set `$SIG{INT}` to `'IGNORE'` before `fork`, and after `fork` install your handler (it should probably be an empty sub, as in `$SIG{INT} = sub {};`)	[reply] [d/l] [select]
Re^3: Allowing user to abort waitpid by salva (Canon) on Mar 07, 2016 at 09:55 UTC
Moving the child to its own process group (`setpgrp(0,0)`) would also avoid getting the INT signal when the user presses a Control-c.	[reply] [d/l]
Re^4: Allowing user to abort waitpid by Anonymous Monk on Mar 07, 2016 at 10:07 UTC
Sure, there is a number of ways to do it. `setpgrp` is not in (Perl's) `POSIX`, but it has `setpgid`. Doing that will have other consequences wrt SIGQUIT, SIGHUP etc. Probably not a problem in practice, though. Come to think of it, system might also be close to what the OP is trying to do...	[reply] [d/l] [select]
Re^5: Allowing user to abort waitpid by Anonymous Monk on Mar 07, 2016 at 10:15 UTC
Re^2: Allowing user to abort waitpid by Anonymous Monk on Mar 07, 2016 at 18:25 UTC
This (waitpid returning) may be the case with OP's legacy environment. Current perl appears to set up the signal handlers with SA_RESTART. In this case, the (wait4) syscall returns ERESTARTSYS and is automatically restarted by the libc wrapper. `#! /usr/bin/perl use strict; use warnings; $SIG{QUIT} = "IGNORE"; my $pid = fork() // die; unless ($pid) { exit !exec "sleep 100"; } $SIG{ALRM} = sub { warn "SIGALRM\n" }; $SIG{QUIT} = sub { warn "SIGQUIT\n" }; warn "childpid = $pid\n"; alarm(2); warn "interrupted\n" while waitpid(-1, 0) == -1 and $!{EINTR};` [download] Your advice is sound, however. Periodic polling is a hackish workaround. Unix has interrupts (`^C ^\`), and where possible, one ought to go with those. The alternative it to handle SIGCHLD and just keep reading/selecting on STDIN.	[reply] [d/l]
Re^3: Allowing user to abort waitpid by Anonymous Monk on Mar 07, 2016 at 19:52 UTC
This (waitpid returning) may be the case with OP's legacy environment... Current perl appears to set up the signal handlers with SA_RESTART Wow, anonymonk... I didn't know that. You're right (well, almost). It's not SA_RESTART, it's `PP(pp_waitpid) { ... if (PL_signals & PERL_SIGNALS_UNSAFE_FLAG) result = wait4pid(pid, &argflags, optype); else { while ((result = wait4pid(pid, &argflags, optype)) == -1 && er +rno == EINTR) { PERL_ASYNC_CHECK(); } } ...` [download] (pp.c) There is some mention in perlipc: On systems that supported it, older versions of Perl used the SA_RESTART flag when installing %SIG handlers. This meant that restartable system calls would continue rather than returning when a signal arrived. In order to deliver deferred signals promptly, Perl 5.8.0 and later do not use SA_RESTART. Consequently, restartable system calls can fail (with $! set to "EINTR") in places where they previously would have succeeded. The default ":perlio" layer retries "read", "write" and "close" as described above; interrupted "wait" and "waitpid" calls will always be retried. Well, I stand corrected, then.	[reply] [d/l]
Re^4: Allowing user to abort waitpid by Anonymous Monk on Mar 07, 2016 at 21:03 UTC
Right, I stand corrected, too. The SA_RESTART is used only when unsafe signals are requested (environment PERL_SIGNALS=unsafe). Thank you.	[reply]
Re^3: Allowing user to abort waitpid by BrowserUk (Patriarch) on Mar 07, 2016 at 19:40 UTC
nixers are a funny bunch. Ask about how to multiplex a few hundred tcp clients transferring gobs of data, and they'll almost universally suggest using a select loop, or other polled event mechanism; which in modern high-speed comms environments requires polling with millisecond or smaller resolution to be responsive to even tens of clients. And that can consume 60% to 70% of a cpu just polling. But ask about getting conditional input from the guy sitting at the keyboard, which requires polling no more than once every 1/10th of a second, which will consume so little cpu that it won't even show; and they call it hackish. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^4: Allowing user to abort waitpid (select) by tye (Sage) on Mar 07, 2016 at 22:12 UTC
select only involves polling when done incorrectly. And that can consume 60% to 70% of a cpu just polling. Yeah, when I use select, it doesn't burn CPU when waiting. - tye	[reply]
Re^5: Allowing user to abort waitpid (select) by Anonymous Monk on Mar 07, 2016 at 23:35 UTC
Re^5: Allowing user to abort waitpid (select) by BrowserUk (Patriarch) on Mar 08, 2016 at 06:50 UTC
Re^4: Allowing user to abort waitpid by Anonymous Monk on Mar 07, 2016 at 20:04 UTC
Not a good example, `select` and `poll` are indeed slow and not recommended for "a few hundren tcp clients"; use `epoll`/`kqueue`/signal-driven IO (well, maybe not signal-driven IO).	[reply] [d/l] [select]
Re^5: Allowing user to abort waitpid by BrowserUk (Patriarch) on Mar 08, 2016 at 11:35 UTC
Re^6: Allowing user to abort waitpid by Anonymous Monk on Mar 08, 2016 at 13:23 UTC
Some notes below your chosen depth have not been shown here