: >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?
Er, nothing. Sorry; hash collision.
: Does that mean that you can't avoid embedded DCL directives and
: just call the real program?
Yes. While it's possible to create a process without a CLI, Perl doesn't
support it, since such processes also lack parts of the environment many
programs expect to be there.
: >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.
Same pages in both processes. Basically, the "child" is really a thread in the
parent until exec() is called. The file descriptor differences show up when
you try to do things like
pipe(RD,WRT);
if ($pid = fork) {
close(WRT);
while <defined($data = <RD>) { do_stuff(); }
}
elsif (not defined $pid) {
die "fork failed: $!";
}
else {
close(RD);
while (<FOO>) { print WRT $foo; }
}
Under VMS both threads are in the same process, so when the "child" closes
WRT, it's gone in the parent, too, and vice versa.
: >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 latter, until you exec().
: >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?
Event flags, in the same situation.
Regards,
Charles Bailey [EMAIL PROTECTED]
