If you are making changes to VMS.C for the safe_popen() stuff, could you test my
change to my_pclose() that I hope to get in soon. It seems to work and pass the
tests, but it's an area related to the work you're doing, so I'd like to get a
consolidated fix here (or perhaps your work would obviate my change).
It seems someone discovered that if a subprocess created by a pipe open say:
open( CMD, "|\@sys\$input" );
would die if the exit status was odd. This causes perl to hang because
my_pclose() tries to do a WRITEOF to the pipe and hangs (the potential reader is
dead). I'm not sure why the subprocess, the @sys$input, hangs around to read an
EOF after a success exit, but it appears to do this. In any case, we can't
depend on a given subprocess, opened by a pipe, will be there. It could get a
bad crash like a corrupted stack frame from which you can't recover, for
example.
I've gotten this to work by putting a IO$M_NOW on the WRITEOF:
retsts = sys$qiow(0,chan,IO$_WRITEOF|IO$M_NOW,iosb,
0,0,0,0,0,0,0,0);
But, I'm not happy with this now. The problem is that the status is checked
from the iosb after this, and I could imagine a case where this would be not set
yet and the iosb could still have an old value and this could turn up an error.
Also, we may actually be interested in some iosb status at a later time, and
making this a nowait write would mean we would have to implement a kludgy
timeout for the WRITEOF to reasonably complete. Sure, we could assume that it's
going to finish in 5 seconds or something if the process is still there, but
this is just sloppy coding. After all, a system _could_ get busy and the child
would be outswapped for a long period.
It appears that the pipe is being opened as a RW mbx (new to some recent version
of OpenVMS), so the perl has READ channels and WRITE channels on the mbx. I
could be wrong about this, but I have reason to believe it (I did an ANAL/SYS
"SHO PROC/CHAN" on a perl that was hung and saw several channels assigned to the
mailbox that it was trying to write the EOF to). I don't see why this should be
necessary. It seems to me that a given pipe mbx should be either READ or WRITE,
but not both.
If this mbx only had write channels assigned by perl, then we could do a:
retsts = sys$qiow(0,chan,IO$_WRITEOF|IO$M_READERCHECK,iosb,
0,0,0,0,0,0,0,0);
Which returns a SS$_NOREADER from the $qiow if there is no reader on the mailbox
(which would be the case if the pipe reading subprocess died). We could test
for this and ignore this.
I find this the most satisfying fix, but it was going to depend on my getting
into safe_popen(). On seeing that you had your hands in it currently, I'm
wondering if you couldn't look into these issues while you are at it. I
certainly wouldn't want to duplicate the work.
I haven't heard from Charles Bailey in awhile. I wonder if he has any ideas
here.
> -----Original Message-----
> From: lane @ DUPHY4.Physics.Drexel.Edu [mailto:lane @
> DUPHY4.Physics.Drexel.Edu]
> Sent: Wednesday, February 23, 2000 10:17 AM
> To: vmsperl @ perl.org
> Subject: RE: Patches for 5.5.650 to build?
>
>
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> > At 12:19 PM 2/22/00 -0800, [EMAIL PROTECTED] wrote:
> >>Jordan Henderson wrote:
> >>
> >> > Thanks. I guess I thought that a lot of these patches you
> >> > mentioned would have been folded into .660. I'll investigate
> >> > each and see if they are and I'll search the archives for others.
> >>
> >>If a patch appears on vmsperl it may be a "what do you folks think
> >>of this?" sort of thing. It needs to go to perl5-porters
> to be "official"
> >>and then there is no guarentee that it will be accepted.
> >
> > On the other hand, Sarathy's pretty cool about VMS-specific
> things, so
> > they're rarely not added.
>
> That's good. I recently started work on building .650 because the
> "stable" Perl release was too far behind on VMS-specific
> fixes. Hopefully
> the next "stable" Perl will have a lot of those fixes.
>
> I guess I should send my "TZ for pre 7.0 systems" patch from last
> summer on to Perl5-porters (a step I neglect far too often). Has
> anyone else here tested it?
>
> In the process of getting not only a clean build of .650 but also
> a clean suite of tests I've run across a number of problems
> ... most are
> the usual "unixisms in the test suite", but some are things that need
> fixed...the major one being subprocess handling in "safe_popen". It
> should be ready for release within a week, but right now there's still
> some lingering bugs.
>
> Meanwhile, I have a "Perl language" question that I hope
> someone can answer...
> in the t/lib/dprof.t test, there's a glob:
> sort(<lib/dprof/*_t lib/dprof/*_v>)
> that fails on VMS...I modified it to:
> sort(<lib/dprof/*_t>,<lib/dprof/*_v>)
> and then it works; apparantly the glob is handled in OP.C in
> a section of
> VMS-specific code, and it expects a single filespec.
>
> What I couldn't find in the docs was any indication that the originial
> form of glob was particularly "valid". Is it? I guess it works for
> *somebody*, otherwise it wouldn't be in the test suite, but it would
> be nice to have some idea as to valid format, separators, etc. if
> you're putting a list of filespecs in the glob.
>
> Which leads to the question: should the VMS-glob handle these "list of
> filespecs" globs, or should it be "don't do that in VMS"?
> --
> Chuck Lane [EMAIL PROTECTED]
>
