At 02:31 PM 3/9/00 -0700, Tom Christiansen wrote:
> >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?
Thinko--probably thinking it meant exclusive access, rather than the "fail
if it exists" flag. It works on VMS.
> >| >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?
Nope. Which can lead to some evil things with embedded @s and such. Ewww.
> >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.
On VMS you don't get a separate process, though, which can cause the odd
problem...
> >| >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?
They don't execute concurrently. fork sort of snapshots things, and an exec
if done after a fork spawns a new subprocess to execute the thing you
exec'd, inheriting files and such the way fork/exec works on Unix. (An exec
without a preceding fork replaces the current image with the new one
without creating a subprocess, like on unix)
> >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?
Not that I see. I don't see much in the way of support for the msg* and
shm* stuff in Dec C 6.2 on VMS 7.2 either. I should put some tests into
subconfigure.com for them anyway, in case they show up at some point.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
