"Craig A. Berry" <[EMAIL PROTECTED]> writes:
>
> That should include all the patches to 5.6.0, though I can't guarantee
> everything is in there. Actually, a quick check shows that Chuck Lane's
> piping stuff is *not* in there. Charles Bailey was, in his words, "working
> them into the repository," but had also expressed some doubt about the
> AST-reentrancy of the C RTL that Chuck's code depends on. I don't remember
> when Charles said he would return from his month away with other duties or
> whether it will be before 5.6.1 goes final.
I haven't heard anything from Charles Bailey recently; last word was that
he was going to try the piping code, but working remotely from Texas to
his microvax here in Philly is painful, not least because of the slowness
of Perl builds on a uV3.
As for the issue of CRTL & AST-reentrancy, didn't we had a DEC/Compaq
person chime in at one point?
A quick look through the code, in the AST routines, shows two CRTL
calls: "close" and "write", and only in one routine:
"pipe_mbxtofd_ast" (this is the routine that pipes subprocess
STDOUT/STDERR to the same place as the parent process STDOUT/STDERR,
when that happens to be a file rather than a MBX or terminal). The
CRTL file descriptor used for the "close" and "write" is obtained via
"dup" and only used by the AST routine, BTW.
Please note that the use of CRTL-based i/o in this one AST routine
seems to be necessary....I would prefer (and spent a lot of time
looking!) for ways that RMS could be used instead. But this would
require using undocumented CRTL hooks that would be IMO much more
fragile than just using "write" in an AST routine.
Without access to the CRTL source listings, my best guess is that "write"
simply updates a RAB (not shared, since the AST routine has exclusive use
of the CRTL file-descriptor) and calls SYS$PUT.
I've subjected this particular bit of code to a significant amount of
"heavy i/o abuse"....since it was in cases of high rates of i/o from both
the parent and the child processes that brought to light the need for
the piping, with retry and timeout handling. These tests attempt to
maximize i/o rates through both the original file-descriptor and the
dup'ed file descriptor used by the AST routine.
You can try the test yourself, it's the "test_contend.pl" test in the
"Pipe Torture Tests" section on http://www.crinoid.com/perl560.htmlx
So I'm pretty confident that (experimentally!) we're AST-safe for VMS 6.2,
further confidence can only come from authoritative statements from
DEC/Compaq or if someone can dredge through the CRTL source.
Earlier versions of VMS/CRTL I have not been able to test, later versions
(7.1) have tested just fine. Please feel free to build with the piping
patch and beat the hell out of the code, I'm quite confident that (a) it
can take it and (b) it's got a lot more functionality than what we
had before.
