I've finally figured out why posix.t test #10 is failing on VMS. It
depends on the ability to call kill() from within a signal handler.
I don't know whether (or why) this is important, but it doesn't work
on VMS, as the following test program in C illustrates:
$ type killtest.c
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
void handler1(int s) { printf("%d",s); kill(getpid(),2); }
void handler2(int s) { printf("%d",s); }
main(){
printf("0");
signal(1,handler1);
signal(2,handler2);
kill(getpid(),1);
sleep(1);
printf("\n");
}
This program prints out "012" on Mac OS X 10.1.3 and Linux PPC 2000,
which are the only unices I have to test with. On VMS 7.3, it prints
out "01"; the second handler never fires. If I use raise() instead
of kill() it does work, but that doesn't help because Perl doesn't
have a raise() and raise() limits me to the current process anyway.
Luckily Chuck Lane's kill() replacement (which he rolled for other
purposes) helps out here as well. The patch below just widens the
circumstances under which it will get used. posix.t #10 is happy now.
--- configure.com;-0 Wed Mar 20 15:10:27 2002
+++ configure.com Sat Mar 23 19:14:03 2002
@@ -4943,24 +4943,29 @@
$ nv_preserves_uv_bits = tmp
$ ENDIF
$!
-$ echo4 "Checking whether your kill() uses SYS$FORCEX..."
+$ echo4 "Checking if kill() uses SYS$FORCEX or can't be called from a signal
+handler..."
$ kill_by_sigprc = "undef"
$ OS
$ WS "#include <stdio.h>"
$ WS "#include <signal.h>"
$ WS "#include <unistd.h>"
-$ WS "void handler(int s) { printf(""%d\n"",s); } "
+$ WS "void handler1(int s) { printf(""%d"",s); kill(getpid(),2); }"
+$ WS "void handler2(int s) { printf(""%d"",s); }"
$ WS "main(){"
$ WS " printf(""0"");"
-$ WS " signal(1,handler); kill(getpid(),1);"
+$ WS " signal(1,handler1);"
+$ WS " signal(2,handler2);"
+$ WS " kill(getpid(),1);"
+$ WS " sleep(1);"
+$ WS " printf(""\n"");"
$ WS "}"
$ CS
$ ON ERROR THEN CONTINUE
$ GOSUB compile
-$ IF tmp .NES. "01"
+$ IF tmp .NES. "012"
$ THEN
-$ echo4 "Yes, it does."
-$ echo4 "Checking whether we can use SYS$SIGPRC instead"
+$ echo4 "Yes, it has at least one of those limitations."
+$ echo4 "Checking whether we can use SYS$SIGPRC instead..."
$ OS
$ WS "#include <stdio.h>"
$ WS "#include <lib$routines.h>"
--- vms/vms.c;-0 Wed Mar 20 16:58:42 2002
+++ vms/vms.c Sat Mar 23 19:19:13 2002
@@ -1096,13 +1096,18 @@
#ifdef KILL_BY_SIGPRC
#include <errnodef.h>
-/* okay, this is some BLATENT hackery ...
- we use this if the kill() in the CRTL uses sys$forcex, causing the
+/* We implement our own kill() using the undocumented system service
+ sys$sigprc for one of two reasons:
+
+ 1.) If the kill() in an older CRTL uses sys$forcex, causing the
target process to do a sys$exit, which usually can't be handled
gracefully...certainly not by Perl and the %SIG{} mechanism.
- Instead we use the (undocumented) system service sys$sigprc.
- It has the same parameters as sys$forcex, but throws an exception
+ 2.) If the kill() in the CRTL can't be called from a signal
+ handler without disappearing into the ether, i.e., the signal
+ it purportedly sends is never trapped. Still true as of VMS 7.3.
+
+ sys$sigprc has the same parameters as sys$forcex, but throws an exception
in the target process rather than calling sys$exit.
Note that distinguishing SIGSEGV from SIGBUS requires an extra arg
[end of patch]
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser