Charles Bailey <[EMAIL PROTECTED]> writes:
> 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.
Yeah, and I'm back in Japan for the next month. So replies will be terse
and rife with typos :-)
>
>> 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.
(digression:)
Craig points out the threaded-Perl problems; I agree entirely, but have
yet to get a threaded perl built. One could easily implement this
particular bit of code as a separate thread (read from MBX, write to file,
filter EOFs) rather than ASTs.
It's just that you don't want to force inclusion of threads to do piped
i/o to subprocesses...so an AST implementation is needed. But if you already
are doing threads, then go with the thread implementation.
All we need is for someone to write it, with an #ifdef for threaded/AST
(back to reply to Charles)
For queuing and writing out later you have some difficulties...."later"
would have to be defined by actions in the main-line code; the subprocess
is asynchronous, so you have to hold onto output even after the subprocess
completes...about the only place you could really define a "dump the
queued stuff to the file" would be when the file is closed.
Would that really be an acceptable form, having the subprocess data
greatly out of sync with the main process output?
As for future changes in the CRTL, Compaq/DEC *could* do all kinds of
stuff to mess us up; but if history is any guide, the CRTL gets more
usable with time, not less.
--
Drexel University \V --Chuck Lane
======]---------->--------*------------<-------[===========
(215) 895-1545 _/ \ Particle Physics
FAX: (215) 895-5934 /\ /~~~~~~~~~~~ [EMAIL PROTECTED]
