"Craig A. Berry" <[EMAIL PROTECTED]> writes:
> I think this is a reproducer for the problem that occasionally
> inserts spurious carriage returns into what should be one line of
> output in the test suite. It appears to be a function of pipe buffer
> size. If the mailbox buffer for a pipe fills up, reading EOF from
> the pipe causes a carriage return to get inserted in the stream.
Well, much of this is from the interaction between the CRTL and
mailboxes. There's a limit to what we can do to wedge our fixes in
between those two. There's a definite limit to what I'm willing to do
to rewrite the CRTL i/o library.
When writing a buffer to a mailbox, any trailing \n gets stripped. \n's
within the buffer are (I *think*) left alone. If the buffer size is larger
than the mailbox then the buffer is chopped up into mailbox-size chunks
and sent as multiple writes.
When reading a buffer from a mailbox, a \n is appended on each buffer
read.
Examples:
w: C: "this is a test\n" -> mbx: "this is a test"
r: mbx: "this is a test" -> C: "this is a test\n"
large string to mbx size 16:
C write: "blah blah blah...yakk yakk\n"
mbx write: "blah blah blah.."
mbx write: ".yakk yakk"
mbx read: "blah blah blah.."
mbx read: ".yakk yakk"
C read: "blah blah blah..\n"
C read: ".yakk yakk\n"
> Perhaps we've been through all this before, but I keep forgetting
> exactly what the problem is. I 've looked at the piping code and
> don't see right off why this is happening, but there's some pretty
> twisty stuff in there.
Augh, no! Please don't make me go back there...
> We could dodge the most common occurrences by
> defaulting to a buffer larger than the current 512, but that caused
> some people BYTLM problems. Hmm, perhaps when Chuck gets through
> grading exams for the semester he'll have a eureka experience on this
> :-).
One of the big difficulties is that one really only has (some) control
of the i/o on the parent process. As any parent can tell you, children
are only marginally controllable :-)
So while one can imagine some sort of Perl-to-perl mailbox protocol that
does the \n handling a bit nicer, how does the parent know that the string
it asked DCL to execute in a child process is going to run Perl? And how
does it know that the string it just read from the child is from Perl or
DCL?
Imagine the following as your CHILD.COM:
$ write sys$output "hi Perl Parent, this is DCL"
$ perl -e"print q(this is Perl\nreally it is\n);"
$ write sys$output "did you get that? Here, have some binary:"
$ copy mypicture.gif sys$output
$ write sys$output "complex enough for you?"
Global section "i/o" fails because we have to be able to have DCL on
the other side of a pipe. Tempfiles for i/o fail because to get
sharing to work we are stuck with record-based i/o and the same \n
problems. And you left out doing i/o via the lock manager, but that
won't work either :)
Named pipes in VMS >7.2 will be a problem because of the installed base
of VMS <=7.2.
---------------------------------------------------------------------
So with all of that negativity out of the way, here's what *might* work:
a hugely complicated "Perl-to-Perl Mailbox Protocol" (P2PMP)
When creating a child process give it a confined logical:
PERLCHILD_P2PMP = "MBXnnnn,MBXmmmm,..." list of mailboxes
In Perl, if $ENV{PERLCHILD_P2PMP} detected, then when i/o is
initialized, before any i/o to MBXnnnn, send a "turn on P2PMP" signal
to let the parent process know to turn on P2PMP. After that,
wrap i/o with something like:
<header sequence>...data... <--sized to fit in MBX
On the parent side, any i/o before the "turn on P2PMP", or any without
a <header sequence> gets the current, normal treatment. Data transmitted
via P2PMP would get unwrapped, catenated, etc. to fix all the \n problems.
(actually, it would be good to use the lock manager to coordinate whether
P2PMP is on or off, but that might have priv/permission difficulties)
To make this work one would have to divert all Perl i/o to go through our
code, and keep track of which channels are special P2PMP ones.
And some people complain that the current piping code is slow compared to
previously! Just *wait*! (and wait...)
--
Drexel University \V --Chuck Lane
======]---------->--------*------------<-------[===========
(215) 895-1545 _/ \ Particle Physics
FAX: (215) 895-5934 /\ /~~~~~~~~~~~ [EMAIL PROTECTED]
