Charles Bailey <[EMAIL PROTECTED]> wrote:
> Charles Lane <[EMAIL PROTECTED]> wrote:
>> to avoid main process hangs. EOFs removed, except for one at
>> child process termination, inserted by process completion code.
> I'm a bit uneasy about this step, since it precludes the subprocess' use
> of EOF (e.g. as an OOB delimiter between messages). I agree that it's
> not the usual case (spawn off a single command and exit), but it might be
> nice to have the option of passing all I/O back to Perl ("raw mode", as
> it were).
Well, it's easy enough to leave in the EOFs from the child and filter
out others from 'grandchildren'...what I do is look at the "sending
PID" (IOSB dvispec field) to see if the EOF is from the parent
process, indicating "child has terminated, this is the REAL end of the
data"; I'd just add a test for the immediate child too. Consider it done.
>> . When child exits, AST routine reads any data written to its MBX
>> and discards, preventing hang of main process.
> Looks like we're still stuck with a race, though, if several processes
> inherited a single mbx. I'm not sure how to fix this, though, short
> of giving each subprocess a new set of mbxen, and having ASTs in the
> parent copy from those to the "apparent" (i.e. inherited or specified
> on the command line) PPFs of the subprocess.
Hold on, I think you've got it mixed up a bit (or I do)...the case mentioned
above is
open(W,"|child")
Maybe the child spawns grandchildren, but they aren't going to get
their grubby little hands on the child's STDIN (STDOUT and STDERR,
yes).
When "child" terminates, it means that any "grandchildren" are terminated
also, so if the parent process does:
print W "still there?\n";
it will hang when the MBX fills, since the child isn't there to read the
MBX. That's what the code mentioned above does...it does a read-and-discard
of data written to an exited child. I don't know how "standard" this
behavior is, but it seemed like the right thing to do.
I'm also adding code that discards *output* from a child/grandchildren
when there's a Perl_my_pclose that indicates the parent won't be reading
any more. The pipe gets fully shut down when the child terminates.
In both of the above cases, the sending code (Perl for a parent,
arbitrary for a child) can't really tell if what it is sending is
received...maybe it makes more sense to have some sort of error return
('broken pipe'), but it's not clear that we can make that happen.
Without either an error condition or a "pipe to NL:", then processes
will hang...an (IMHO) unacceptable outcome.
The error condition on i/o to an exited child is difficult to produce,
simply because the $QIO we need to have return an error is generated
by the CRTL...we don't have it's channel # to do a $CANCEL on it. And
the mailbox isn't going to be deleted until that channel is
deassigned.
It's worse for a child writing to a parent that has closed its input;
the child has no way to tell that the parent has taken that action,
and (in the parent) we don't have a way to $CANCEL or otherwise have
the child's $QIO return an error.
Given the above constraints, having the "unwanted output" discarded seemed
the best option.
>> o Error messages ("%SYSTEM-F-ABORT") at Perl exit should be supressed
>> in subprocesses. They're still present for main process.
> I'm also uneasy about this one. It works nicely for the test suite, but
> it's important that the subprocess mechanism remain as generally useful
> as possible, and I'm uncomfortable with things that make it impossible to
> get at some of the subprocess' output (e.g. the !AS replacements in an
> error message). The pragma option discussed in a later message sounds
> nice, but I'd default it to "messages on"; we can shut it off for the
> regression tests, since we control the environment.
I'd think the default should be "unixoid"...much like the situation
with vmsish/unixish times, but would like to hear if anyone is really
using those messages....as opposed to just ignoring or filtering them
out. Generally any VMSish error messages that actually have some content
(as opposed to the general %SYSTEM-F-ABORT) are preceeded by a more
useful Perl-generated message.
As for !AS replacements, it's "my_exit" that is affected (not
lib$signal), so there's nothing put in any !AS fields anyway.
>> o Default MBX size for communication with subprocesses should be
>> decreased, and be settable at runtime via logical.
> Sounds good. One caveat for programmers: if the $QIOs which hang on
> full buffer happen to be the ASTs we're adding, the process'll end up
> RWASTed -- we might make sure NORSWAIT is specified for these $QIOs.
The only place I do a QIO inside an AST is the pipe-and-filter-EOFs when you
open(R,"child|");
and there it doesn't read more from the child until the previous write
to the parent completes...thus, the MBX is always empty when the AST
routine does a write to it. This avoids the potential RWAST, as well as
for dropped i/o that NORSWAIT would lead to.
--
Drexel University \V --Chuck Lane
----------------->--------*------------<[EMAIL PROTECTED]
(215) 895-1545 / \ Particle Physics [EMAIL PROTECTED]
FAX: (215) 895-5934 /~~~~~~~~~~~ [EMAIL PROTECTED]
