develooper Front page | perl.vmsperl | Postings from June 2002

[PATCH RC2] VMS nits, add getppid(), admit absence of fork()

From:
Craig A. Berry
Date:
June 25, 2002 19:52
Subject:
[PATCH RC2] VMS nits, add getppid(), admit absence of fork()
Message ID:
a05111b00b93ec39cdf8f@[172.16.52.1]
This patch modifies:

configure.com
pod/perlport.pod
vms/perlvms.pod

There are three changes here to configure.com to handle issues that have 
come up during further testing of RC2.

1.) Peter Prymmer noticed that getppid() was hard-coded as unavailable even 
though it's been present in the C library since forever, so we added a test 
for it and enable it if we find it.

2.) Martin Vorlaender encountered an error that caused configure.com to bail out 
when testing for the presence of gcc on OpenVMS VAX 6.2.  Peter submitted a small 
fix that solved the problem.

3.) There is a tweak here to the handling of threading defaults due to something 
I didn't get quite right in #17334.

The rest of the patch is documentation only.  We updated perlport.pod and 
perlvms.pod to recognize the availability of getppid().  

I also brought the documentation into alignment with reality about the 
presence (or actually absence) of fork().  We do not have fork() now, we did 
not have it in 5.6.x, and we did not have it in 5.005_03.  I don't think we 
ever had it, though it's possible we did a very long time ago and some 
change to Perl_pp_fork() pulled it out from under us.  If so, that happened 
before 5.005_03.  The documentation claiming we have it goes back to at 
least 5.003; I have a feeling it's something Charles Bailey planned but 
never finished implementing.  In any case, I think the only thing to be done
at the moment is change the docs.  In the 5.9.x time frame various 
other possibilities exist.

All tests are successful with -"des" and -"Duseithreads" 
configurations on recent versions of OpenVMS Alpha.  Build reports 
are sparse, but it looks like there may be some remaining issues on 
older (pre-7.0) systems.

--- configure.com_orig;-0       Mon Jun 24 11:29:58 2002
+++ configure.com       Mon Jun 24 12:00:32 2002
@@ -1540,12 +1540,12 @@
 $ WRITE CONFIG "}"
 $ CLOSE CONFIG
 $!
-$! DEFINE SYS$ERROR _NLA0:
-$! DEFINE SYS$OUTPUT _NLA0:
+$ SET NOON
+$ DEFINE/USER_MODE SYS$ERROR _NLA0:
+$ DEFINE/USER_MODE SYS$OUTPUT _NLA0:
 $ cc/NoObj/list=ccvms.lis ccvms.c
 $ tmp = $status
-$! DEASSIGN SYS$OUTPUT
-$! DEASSIGN SYS$ERROR
+$ SET ON
 $ IF (silent) THEN GOSUB Shut_up
 $ IF tmp.NE.%X10B90001
 $ THEN 
@@ -1565,9 +1565,9 @@
 $   THEN 
 $     echo "Will try cc/decc..."
 $   ENDIF
+$   SET NOON
 $   DEFINE/USER_MODE SYS$ERROR NL:
 $   DEFINE/USER_MODE SYS$OUTPUT NL:
-$   SET NOON
 $   cc/decc/NoObj/list=ccvms.lis ccvms.c
 $   tmp = $status
 $   SET ON
@@ -1591,10 +1591,12 @@
 $Gcc_initial_check:
 $ echo "Checking for gcc"
 $ OPEN/WRITE CONFIG gccvers.lis
+$ SET NOON
 $ DEFINE/USER_MODE SYS$ERROR CONFIG
 $ DEFINE/USER_MODE SYS$OUTPUT CONFIG
 $ 'gcc_symbol'/noobj/version _nla0:
 $ tmp = $status
+$ SET ON
 $ IF (silent) THEN GOSUB Shut_up
 $ CLOSE CONFIG
 $ IF (tmp.NE.%X10000001).and.(tmp.ne.%X00030001)
@@ -2337,7 +2339,7 @@
 $     bool_dflt = "y"
 $     if f$type(useithreads) .nes. ""
 $     then
-$         if .not. useithreads .or. useithreads .eqs. "undef" then bool_dflt="n"
+$         if useithreads .eqs. "undef" then bool_dflt="n"
 $     endif
 $     if f$type(use5005threads) .nes. ""
 $     then
@@ -3374,6 +3376,25 @@
 $ GOSUB inhdr
 $ i_unistd = tmp
 $!
+$! do we have getppid()?
+$!
+$ IF i_unistd .EQS. "define"
+$ THEN
+$   OS
+$   WS "#include <stdio.h>"
+$   WS "#include <unistd.h>"
+$   WS "int main() {"
+$   WS "printf(""%d\n"",getppid());"
+$   WS "return(0);"
+$   WS "}"
+$   CS
+$   tmp = "getppid"
+$   GOSUB inlibc
+$   d_getppid = tmp
+$ ELSE
+$   d_getppid = "undef"
+$ ENDIF
+$!
 $!: see if this is a libutil.h system
 $!
 $ tmp = "libutil.h"
@@ -5253,7 +5274,7 @@
 $ WC "d_getpgid='undef'"
 $ WC "d_getpgrp2='undef'"
 $ WC "d_getpgrp='undef'"
-$ WC "d_getppid='undef'"
+$ WC "d_getppid='" + d_getppid + "'"
 $ WC "d_getprior='undef'"
 $ WC "d_getprotoprotos='" + d_getprotoprotos + "'"
 $ WC "d_getprpwnam='undef'"
--- pod/perlport.pod;-0 Sat Jun  8 18:23:29 2002
+++ pod/perlport.pod    Tue Jun 25 15:32:32 2002
@@ -1567,7 +1567,7 @@
 
 =item fork
 
-Not implemented. (S<Mac OS>, AmigaOS, S<RISC OS>, VOS, VM/ESA)
+Not implemented. (S<Mac OS>, AmigaOS, S<RISC OS>, VOS, VM/ESA, VMS)
 
 Emulated using multiple interpreters.  See L<perlfork>.  (Win32)
 
@@ -1584,7 +1584,7 @@
 
 =item getppid
 
-Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>)
+Not implemented. (S<Mac OS>, Win32, S<RISC OS>)
 
 =item getpriority WHICH,WHO
 
--- vms/perlvms.pod;-0  Sat Jun  1 12:03:52 2002
+++ vms/perlvms.pod     Tue Jun 25 16:36:46 2002
@@ -338,7 +338,7 @@
     caller, chdir, chmod, chown, chomp, chop, chr,
     close, closedir, cos, crypt*, defined, delete,
     die, do, dump*, each, endpwent, eof, eval, exec*,
-    exists, exit, exp, fileno, fork*, getc, getlogin,
+    exists, exit, exp, fileno, getc, getlogin, getppid,
     getpwent*, getpwnam*, getpwuid*, glob, gmtime*, goto,
     grep, hex, import, index, int, join, keys, kill*,
     last, lc, lcfirst, length, local, localtime, log, m//,
@@ -358,8 +358,8 @@
 and calling them produces a fatal error (usually) or 
 undefined behavior (rarely, we hope):
 
-    chroot, dbmclose, dbmopen, flock,
-    getpgrp, getppid, getpriority, getgrent, getgrgid,
+    chroot, dbmclose, dbmopen, flock, fork*,
+    getpgrp, getpriority, getgrent, getgrgid,
     getgrnam, setgrent, endgrent, ioctl, link, lstat,
     msgctl, msgget, msgsend, msgrcv, readlink, semctl,
     semget, semop, setpgrp, setpriority, shmctl, shmget,
@@ -482,49 +482,30 @@
 
 =item exec LIST
 
-The C<exec> operator behaves in one of two different ways.  
-If called after a call to C<fork>, it will invoke the CRTL 
-C<execv()> routine, passing its arguments to the subprocess 
-created by C<fork> for execution.  In this case, it is 
-subject to all limitations that affect C<execv()>.  (In 
-particular, this usually means that the command executed in 
-the subprocess must be an image compiled from C source code, 
-and that your options for passing file descriptors and signal 
-handlers to the subprocess are limited.)
-
-If the call to C<exec> does not follow a call to C<fork>, it 
-will cause Perl to exit, and to invoke the command given as 
-an argument to C<exec> via C<lib$do_command>.  If the argument 
-begins with '@' or '$' (other than as part of a filespec), then it 
-is executed as a DCL command.  Otherwise, the first token on 
-the command line is treated as the filespec of an image to 
-run, and an attempt is made to invoke it (using F<.Exe> and 
-the process defaults to expand the filespec) and pass the 
-rest of C<exec>'s argument to it as parameters.  If the token
-has no file type, and matches a file with null type, then an
-attempt is made to determine whether the file is an executable
-image which should be invoked using C<MCR> or a text file which
-should be passed to DCL as a command procedure.
-
-You can use C<exec> in both ways within the same script, as 
-long as you call C<fork> and C<exec> in pairs.  Perl
-keeps track of how many times C<fork> and C<exec> have been
-called, and will call the CRTL C<execv()> routine if there have
-previously been more calls to C<fork> than to C<exec>.
+A call to C<exec> will cause Perl to exit, and to invoke the command
+given as an argument to C<exec> via C<lib$do_command>.  If the
+argument begins with '@' or '$' (other than as part of a filespec),
+then it is executed as a DCL command.  Otherwise, the first token on
+the command line is treated as the filespec of an image to run, and
+an attempt is made to invoke it (using F<.Exe> and the process
+defaults to expand the filespec) and pass the rest of C<exec>'s
+argument to it as parameters.  If the token has no file type, and
+matches a file with null type, then an attempt is made to determine
+whether the file is an executable image which should be invoked
+using C<MCR> or a text file which should be passed to DCL as a
+command procedure.
 
 =item fork
 
-The C<fork> operator works in the same way as the CRTL 
-C<vfork()> routine, which is quite different under VMS than 
-under Unix.  Specifically, while C<fork> returns 0 after it 
-is called and the subprocess PID after C<exec> is called, in 
-both cases the thread of execution is within the parent 
-process, so there is no opportunity to perform operations in 
-the subprocess before calling C<exec>.
-
-In general, the use of C<fork> and C<exec> to create 
-subprocesses is not recommended under VMS; wherever possible, 
-use the C<system> operator or piped filehandles instead.
+While in principle the C<fork> operator could be implemented via
+(and with the same rather severe limitations as) the CRTL C<vfork()>
+routine, and while some internal support to do just that is in
+place, the implementation has never been completed, making C<fork>
+currently unavailable.  A true kernel C<fork()> is expected in a
+future version of VMS, and the pseudo-fork based on interpreter
+threads may be available in a future version of Perl on VMS (see
+L<perlfork>).  In the meantime, use C<system>, backticks, or piped
+filehandles to create subprocesses.
 
 =item getpwent
 
[end of patch]


-- 
________________________________________
Craig A. Berry
mailto:craigberry@mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About