[Info-vax] QIO Writes to a mailbox

[Johnny Billquist]

On 2011-11-07 17.05, George Cornelius wrote:
> JF Mezei wrote:
>> And if a mailbox is full, I know that QIOW will cause process to hang on
>> a RWMBX, but would a QIO also result in this ?
>
> Yes, a QIO hangs on a full mailbox - just checked it. Quite irritating,
> because even the debugger is blocked while in RWMBX.

There are additional RW conditions you can get stuck in while doing a 
QIO, so it is not actually even limited to mailboxes.
Every QIo needs dynamic memory for the actual I/O request to be queued. 
If you're out of quota, or already have enough outstanding I/Os in 
progress, you'll also get into a RW.

> Oh, and my idea of both buffers possibly being mapped into memory at the
> same
> time before a transfer occurs is flawed. It's called 'buffered' I/O, after
> all, and that means that (1) transfers go through nonpaged pool and (2) a
> caller's buffer is not locked into physical memory while his I/O remains
> active.

Yes. But I don't actually think that the mailbox I/O as such goes 
through buffered I/O. But the creation of the mailbox itself will use up 
a bunch of nonpaged pool from your quota. But that is a static 
allocation at mailbox create time. After that, the I/O to it, as such, 
don't need more nonpaged pool (except of course for the I/O request itself).

> It is not clear to me what it is about a QIO to a full mailbox that
> should make
> the entire process go unresponsive. Mailboxes are already quite limited,
> so we
> generally cannot work around a size issue by making the mailbox have
> more quota.

Right.

> It would seem, then, that the least that could be done would be to invent a
> modifier to allow the I/O to just remain queued until space became
> available,
> realizing, of course, that interesting things could happen if such a
> pending
> I/O were cancelled when there were others queued behind it.

That was what I initially thought VMS would do, but it appears it do 
not. Stupid, in my opinion, but I guess that's the easiest way. Nothing 
strange I can see in cancelling an I/O operation that is queued, which 
have not been processed yet. You remove it from the queue. I/O 
operations queued behind it stay in place, but get closer to the front 
of the queue.

However, what you can do is request that in case of no resources (such 
as a full mailbox), the QIO should not block in RWMBX, but instead 
return with the I/O giving an error that it would have blocked because 
of lack of resources. Then you can retry it later, hopefully succeeding. 
This would allow you to not block on full mailboxes, and yet still be 
doing things asynchronous.

	Johnny