On Sat, 2005-10-22 at 17:02, Craig A. Berry wrote: > At 4:19 PM -0400 10/22/05, John E. Malmberg wrote: > > >>>* Bash shell support. This needs lots of work. Pipes need to be fixed. > >> In principle, just replacing my_popen() and my_pclose() in vms/vms.c > >>with another implementation would be all that's needed. Also, > >>Perl_my_waitpid() would need some work. I think the choice of a pipe > >>implementation should be a configure-time option, though, as folks on > >>older versions of VMS will probably be best served by what we've got > >>now, and in fact there's no proof as yet that currently available > >>alternatives are better. > > > >Actually what Perl has is not too bad, and is much better than the pipe > >implementation in the C library. I recently used what I had learned about > >how perl works to implement a fix to Bash to eliminate the RWMBX hangs while > >running configure scripts. > > Cool. Chuck Lane gets all the credit for Perl's pipe implementation, > and he was driven to it by exactly the types of hangs you describe.
(pardon if, being out of touch for so long, I just rehash stuff that's old news) That's exactly right...trying to get through the testsuite and having tons of RWMBX'd processes was driving me nuts. But frankly, the resulting code *is* confusing, because it went through a rather intense evolutionary process, involving some of the least-well documented features and limitations of VMS V6.2 and earlier. In particular, I recall a long back-and-forth between myself and Charles Bailey to reduce or eliminate possible security holes when creating and using tempfiles as COM files for subprocesses. > > >What I need to do is find out where the extra newlines are being added, > >because when I recreated the algorithm for bash, I did not end up with extra > >new lines. I also do not seem to be having the problem with truncated lines > >either. > > As I understand the problem, there is a fundamental gotcha when > implementing a stream-oriented interface using a record-oriented > gizmo like a mailbox, or at least there is when the main purpose is > inter-process communication. You can emulate streams to some extent > by using buffering, so that you accumulate writes until you see a > newline character, at which point you do the actual write, creating a > record in the mailbox only when you want the reader to see a record > boundary. But sometimes you have to flush your buffer or you will > end up with hangs while the reader sits around waiting for a write > that has been buffered. And of course your buffer will sometimes > fill up and you have to go ahead and write it out before you have a > complete record. > > My guess, though I've never pinned it down and watched it happen in > the debugger, is that when we see spurious newlines, it's because a > flush has taken place or the buffer has filled up. There is lots and > lots of flushing in the Perl test suite; you may just not have as > much flushing in what you're doing with bash. Mailbox size limitations are the culprit; you'd think "oh, just make the mailboxes really huge", but that runs into the limits of normal "user" accounts. Having Perl run fine for SYSTEM, but fail mysteriously for JOE_USER, is not something that I wanted. Even so, one has to increase the default mbx size to get the testsuite to work; or at least that's the way it used to be when I was paying more attention to it. There's a logical you can set to change the "default" mailbox size that might be helpful for tracking down if this is the problem. So yes, the mailboxes have to be flushed if things get too big. IIRC, I tried to have the mbx i/o be "binmode", i.e., only explicit line terminations, rather than at record boundaries; which works fine if you have a "cooperating" process at the other end (Perl), but not when it's a DCL command. What a pain. If one is going revisit the pipe code (a good idea; my work on it stalled for lack of time, not lack of things to do) it would be good to make use of (and extend) the "Pipe Torture Tests" (at the bottom of http://www.crinoid.com/perl560.htmlx), which were designed to expose pipe i/o problems. -- Drexel University \V --Chuck Lane ======]---------->--------*------------<-------[=========== (215) 895-1545 _/ \ Particle Physics FAX: (215) 895-5934 /\ /[EMAIL PROTECTED]
