>Note that O_EXCL is the default under VMS Perl for all file opens; if you
>want shared access you need to ask specifically (for whcih the routines
>VMS::Stdio::vmsopen() and VMS::Stdio::vmssysopen() are provided).
Um, what does O_EXCL have to do with shared access?
>| >2. Running command in system (or exec) and backticks
>| >
>| > system("cmd arg1 arg2") # possible shell intervention
>| > system("cmd", "arg1", "arg2") # unmolested execvp
>|
>| Both work. Identically, as it turns out.
>Both go through the CLI.
Does that mean that you can't avoid embedded DCL directives and
just call the real program?
>PTYs are probably the way to go here. The up-and-coming pipe fixes will also
>help.
I sure wish everyone could use PTYs if they wanted. This would solve
many problems.
>implicit fork constructs do work, but afterwards both "parent" and "child"
>execute in the same context (i.e. same file descriptors, same locks, etc.).
Works that way on Unix (generally), too, as far as files and their locks
(flock not fcntl). It's the data pages that are the general concern.
>| >6. Explicit forks
>| >
>| > if (defined($pid = fork) { parent() }
>| > elsif (!defined $pid) { die "fork: $!" }
>| > else { child() }
>|
>| No. VMS doesn't fork, though we could open things up so a fork then exec
>| works. There's support for that. (Basically some process state is
>It works currently, but with the caveat above. Basically, you're OK iff
>the only thing in the child() branch above is exec qw(some child thing).
So, they don't execute concurrently, or they do, but have the same
data not copies, so are dangerous?
>The msg* and shm* wrappers are in newer DECCRTLs, but we don't go after 'em.
>Better still would be an interface to native global sections.
I should imagine so. Hm... any semaphores?
--tom
