Charles Lane <[EMAIL PROTECTED]> wrote:
>
> 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.
OK, partially back online after a long absence, so please forgive the
disorientation. I was running into a number of failures with the
piping code on a VAX, at least some of which were latent memory alignment
issues. I'd started to test your latest fix when I left for the ICU, and
will try to pick up in spare moments now that I've got at least some
evenings back.
> 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.
Thanks for the description. I'd been meaning to sort through this, but
the tuit drought supervened. This is the root ofomy concern, since CRTL
routines aren't guaranteed to be AST-reentrant. It looks like there
isn't a problem now, but my concern was that a future CRTL would use
AST-level code in write() or close() (e.g. if the CRTL ever gets to
nix-like async I/O) which would cause Perl to hang here. (Of course,
this implies the CRTL using user-mode ASTs.) I'm not necessarily opposed
to using the existing code, since it confers a lot of benefits, but it'd
be nice to see whether we could either get at the file from RMS (unlikely
because of locking issues, since we'd need to re-open it from RMS) or enqueue
these data at AST level and do the actual writing outside the AST (though that
might imply deferring the writes for a long time, since we'd have to intercept
an explicit write/flush/close to the file and actually write the data then).
I'm sorry I can't make more meaningful suggestions; I haven't had time to
really grok the current code.
Regards,
Charles Bailey <[EMAIL PROTECTED]>
