> -----Original Message-----
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 23, 2000 12:32 PM
> To: Jordan Henderson; 'Craig A. Berry'; [EMAIL PROTECTED]
> Subject: RE: Patches for 5.5.650 to build?
>
>
> At 12:14 PM 2/23/00 -0500, Jordan Henderson wrote:
> > > From: Craig A. Berry [mailto:[EMAIL PROTECTED]]
> >What could perl possibly do with an unsuccessful EOF write to the
> >mailbox anyway?
>
> Beats me. Part of me thinks that it ought to be noted. (Maybe
> a warning)
>
> >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).
>
> Huh? CHANNELCNT's a per-process setting, with MAXCHANNELCNT
> being a cap.
> The max number of channels on a system is
> MAXPROCESSCNT*MAXCHANNELCNT.
> (more or less--the spelling's probably wrong)
Well, I was confused, it's not MAXCHANNELCNT, the SYSGEN
parameter is CHANNELCNT and it's the number of _permanent_
I/O channels available to the system.
These mailboxes do not have permanent I/O channels assigned
in any case.
Is there a per-process limit on channels? It's not an
Authorize setting and I don't see a SYSGEN parameter.
>
> Worst case you blow your own, which is not great, but not
> fatal to the
> system. Leaks still suck, though.
>
I'm not sure there's a leak involved here, as all channels
are eventually deassigned. Hmmm... wasn't there a patch
that someone showed how to get Perl to leak channels recently?
> >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.
>
> I think you're right, and it makes sense.
>
Well, it gets complicated. We currently create the
subprocesses via LIB$SPAWN. This gives no control over
how these files are opened, so we'd have to go with setting the
mailbox mode on the $crembx call and not on the $assign call.
It also gives no control over SYS$ERROR at all (it always gets
assigned the same thing as SYS$OUTPUT). So, for open3, we'd have
to change this to a SYS$CREPRC call.
> Dan
>
> --------------------------------------"it's like
> this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
>
