Another reason for home-grown kill() on VMS.
authorCraig A. Berry <craigberry@mac.com>
Mon, 2 Sep 2013 21:19:41 +0000 (16:19 -0500)
committerCraig A. Berry <craigberry@mac.com>
Mon, 2 Sep 2013 21:19:41 +0000 (16:19 -0500)
For some time now Perl has provided its own kill() function on VMS
due to various problems with the system-supplied one, notably that
when called from within a signal handler, the second signal never
got delivered.  This has at long last been corrected in the OS
as of the VMS84I_SYS V3.0 ECO.

But this exposes another problem with the CRTL's kill(), which is
that when called with a signal value of 0 it actually kills the
running program instead of restricting itself to error checking
as the standard requires.  This turns out to be documented behavior
and the documented workaround is to define the _POSIX_EXIT macro.

However, universally changing the behavior of the exit() function
in order to prevent

  kill(getpid(),0);

from bringing down the program that calls it doesn't seem like the
right trade-off.  So just add one more condition to the list of
conditions under which we'll use our own kill().

configure.com

index 3c0da48..97c36fc 100644 (file)
@@ -5777,7 +5777,8 @@ $     d_signbit = "undef"
 $     echo4 "Nope."
 $ ENDIF
 $!
-$ echo4 "Checking if kill() uses SYS$FORCEX or can't be called from a signal handler..."
+$ echo4 "Checking if kill() uses SYS$FORCEX, can't be called from a signal handler,"
+$ echo4 "or fails to handle a signal value of zero..."
 $ kill_by_sigprc = "undef"
 $ OS
 $ WS "#include <stdio.h>"
@@ -5791,12 +5792,13 @@ $ WS "    signal(1,handler1);"
 $ WS "    signal(2,handler2);"
 $ WS "    kill(getpid(),1);"
 $ WS "    sleep(1);"
-$ WS "    printf(""\n"");"
+$ WS "    kill(getpid(),0);"
+$ WS "    printf(""3\n"");"
 $ WS "}"
 $ CS
 $ ON ERROR THEN CONTINUE
 $ GOSUB compile
-$ IF tmp .NES. "012"
+$ IF tmp .NES. "0123"
 $ THEN 
 $   echo4 "Yes, it has at least one of those limitations."
 $   echo4 "Checking whether we can use SYS$SIGPRC instead..."