> -----Original Message-----
> From: Craig A. Berry [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 23, 2000 11:40 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Patches for 5.5.650 to build?
>
>
> At 10:56 AM 2/23/00 -0500, Jordan Henderson wrote:
> >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.
>
> Perhaps I'm misunderstanding this, but I always thought that
> as long as you're doing a $qiow rather than a $qio, the iosb
> will be filled in properly when the call returns. Moreover,
> the I/O User's Guide says, "IO$M_NOW---Completes the I/O
> operation immediately with no wait for a write request from
> another process," which suggests that it just means we aren't
> waiting for another process before executing the I/O. It
> doesn't mean we complete the I/O asynchronously in the
> current process. Sorry if I've misunderstood.
No, I was confused, you are correct. The iosb will have a success
status unconditionallywith IO$M_NOW, but it still seems sloppy to
me to not have the real status of the IO unavailable. The subtle
difference between a qiow() with an IO$M_NOW qualifier and a qio()
without is that you have to wait on a good iosb status with qio().
I was confusing the two.
Maybe I'm worrying too much and IO$M_NOW is all that's needed there.
What could perl possibly do with an unsuccessful EOF write to the
mailbox anyway?
>
> >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.
>
> I'm not sure I understand how you could have 2-way
> communication if the mailbox is not RW. I don't know if
> vmsperl uses the pipe() function from the C RTL or cooks its
> own, but there is a description of how the parent and child
> communicate through a mailbox in the RTL version at:
>
<http://www.openvms.digital.com/commercial/c/5763p037.htm#index_x_1107>
Perl does not use the pipe() call, but rolls it's own.
It appears, from further research, that the default mode
of mailboxes is now read/write. I don't believe this was
once the case, but this was probably changed about 10 years
ago without my noticing :-). I did notice the introduction of
r/w mailboxes, but I didn't notice that they were the default
now. Does anyone remember when this was introduced?
You have to specify explicitly read or write only channels
when you create or assign channels to the mailbox
(see OpenVMS I/O User's Reference Manual,
Section 4.1.1
<http://www.openvms.digital.com:8000/72final/6136/6136pro_013.html#mailbox_chap7
>).
It seems that it would be easy to "fix" this, as the call in
VMS.C, safe_popen(), has a mode argument for r/w. It seems that
this would be "cleaner" in that it would cause an error if some
maintainer of VMS.C incorrectly caused a read to a write pipe or
vice-versa. It would also save channels, which is not an
insignificant consideration as you can run out of channels
system-wide (MAXCHANNELCNT).
Making these changes may also help in work toward the infamous,
ice-cream-prize-winning from Dan, open2 and open3 calls. I know
if I were doing the implementing, I'd want the various mbxs to
be read-only or write-only to keep me from confusing them during
debugging.
Then, the WRITEOF call could use the IO$M_READERCHECK and fail
"gracefully" if the reader had died, rather than just WRITEOF
with a nowait qualifier. Again, this may be straining at gnats.
I still see no problem with not waiting for the reader to read
the mailbox after a WRITEOF. After all, the next thing that perl
does is deassign the channel to that mbx so who cares if the
reader is reading the mailbox or not?
_____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
