perlipc.pod: fix the "exec from signal handler" example

[stepnem]

I was scratching my head wondering why my signal handlers
calling exec[1] didn't work, and neither did the perlipc
example.

Fortunately a search turned up
https://www.perlmonks.org/?node_id=440900 which still cites
the old (and apparently still correct) documentation.

I don't know if something changed since 2011 or if the
pertinent changes in commit de7ba51 were wrong to begin
with.

For convenience I've also put the test script demonstrating
the issue (included in the commit message, with further
details) into a gist:

https://gist.github.com/stepnem/738d7d2e21bc4ab3d1d0a715c4a8bf86

[1] Note that the exec seems important; a simpler handler
(e.g., just printing or setting a variable) appears to work
fine without POSIX.

[Leont]

I don't know if something changed since 2011 or if the
pertinent changes in commit de7ba51 were wrong to begin
with.

Yeah I may have removed too much in that example.

[stepnem]

Yeah I may have removed too much in that example.

Thank you for having a look. Having reread the man page (and relevant parts of POSIX and Linux docs), I realize the paragraph I restored really talks about an unrelated issue, which (as mentioned in de7ba51 commit message) is unlikely to occur nowadays, so let's keep that removed. The POSIX::sigaction (and SA_NODEFER) is needed here only because the signal handler calls exec: by default (with a plain %SIG handler) the handled signal is blocked (added to process signal mask) while the handler function runs, but here it never returns (calling exec) and the signal mask is preserved across execve, preventing further instances of the signal from being delivered to the new process. Perhaps let's also improve the code comment a bit to explain the SA_NODEFER usage.

[Leont]

Perhaps let's also improve the code comment a bit to explain
the SA_NODEFER usage.

Maybe, or maybe it should instead use sigprocmask in the sighandler to reset the mask right before the exec. That sounds easier to me.

[stepnem]

Maybe, or maybe it should instead use `sigprocmask` in the sighandler to reset the mask right before the `exec`

Yeah, although if the concern is avoiding the window for another SIGHUP in the handler function before exec, wouldn't it be better to unblock SIGHUP unconditionally in the main program (outside the handler)? (Possibly for other reasons as well: after all, the signal might also be added to procmask by something else before executing the program; also, the perl POSIX module has the following caveat for sigprocmask: "Note that you can't reliably block or unblock a signal from its own signal handler if you're using safe signals.")

[jkeenan]

@stepnem, we have certain metadata checks that are preventing your pull request from being tested by our continuous integration rig. Could you please do the following:

1. Run perl Porting/updateAUTHORS.pl. This will add your name and email address to the correct location in our AUTHORS file.
2. Apply the following patch to pod/perlipc.pod. This will have your p.r. conform to our line-length standards.

diff --git a/pod/perlipc.pod b/pod/perlipc.pod
index b14e8344b7..5169aed767 100644
--- a/pod/perlipc.pod
+++ b/pod/perlipc.pod
@@ -211,7 +211,8 @@ info to show that it works; it should be replaced with the real code.
 
   # Make sure SIGHUP isn't blocked (as it normally would be, due to the
   # handler function calling exec rather than returning)
-  POSIX::sigprocmask(&POSIX::SIG_UNBLOCK, POSIX::SigSet->new(&POSIX::SIGHUP));
+  POSIX::sigprocmask(&POSIX::SIG_UNBLOCK,
+    POSIX::SigSet->new(&POSIX::SIGHUP));
 
   code();

Please run make test_porting to make sure all metadata tests pass, then re-push the p.r. Thanks.

[Leont]

Yeah, although if the concern is avoiding the window for
another SIGHUP in the handler function before exec, wouldn't
it be better to unblock SIGHUP unconditionally in the main
program (outside the handler)?

I don't think that is a concern.