Hmmm... I declared victory against this bug yesterday by adding IO$M_READERCHECK
to that IO$WRITEOF, but now, I can't get that to work. It appears that the perl
process has read channels open to that mailbox (it's a read/write mailbox).
I can get it to work with IO$M_NOW (instead of IO$M_READERCHECK). I was trying
that at about the same time I saw the documentation on IO$M_READERCHECK. I must
have been exeuting the IO$M_NOW version instead of the IO$M_READERCHECK version
when I declared victory.
This definitely requires more careful testing. I recall being vaguely uneasy
about using IO$M_NOW, but I don't really see a problem with it now. Perl
deassigns the channel right after the QIOW (waits for the WRITEOF to be queued
successfully and then deassigns the channel). I think that's OK.
More testing, some research, more testing...
-----Original Message-----
From: Craig A. Berry
To: [EMAIL PROTECTED]
Sent: 2/19/00 1:57 AM
Subject: Re: Executing DCL-commands from Perl programs
At 3:26 PM -0800 2/18/2000, Brad Hughes wrote:
>Jordan Henderson wrote:
>>
>> That's a bug, allright.
>>
>> Looks to me like it's my_pclose() in VMS.C gets hung up trying to
write an EOF
>> to the pipe. I haven't really debugged it, but I have some inductive
reasons to
>> believe this.
>>
>
>I very vaguely recall Charles mentioning something about this, or
something
>closely related, some time ago. You might want to check the archives.
. . . and search for openpid.t, although I don't know whether all the
cases where that test hangs up are cases where all the mailbox readers
are gone.
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
