[Info-vax] Large mailboxes

[Jan-Erik Söderholm]

Den 2020-11-28 kl. 03:47, skrev Arne Vajhøj:
> On 11/27/2020 9:00 PM, Jan-Erik Söderholm wrote:
>> Den 2020-11-27 kl. 23:41, skrev Arne Vajhøj:
>>> On 11/26/2020 1:27 PM, Arne Vajhøj wrote:
>>>> On 11/26/2020 11:30 AM, Marc Van Dyck wrote:
>>>>> So my question is, why this limitation ? Is it just because when this
>>>>> interface was written, noone imagined that there could ever be a
>>>>> mailbox with more than 64k outstanding messages ? Or am I really going
>>>>> to break something other than this counter if I try loading more
>>>>> than 64k messages ?
>>>>
>>>> I don't know.
>>>>
>>>> But it seems likely that noone imagined it being a problem.
>>>>
>>>> It uses non-paged pool. How big was available non-paged pool on
>>>> VAX systems?
>>>>
>>>> My guess is that available non-paged pool divided by a
>>>> normal message size would fit into 16 bit.
>>>
>>> I could add that as a rule of thumb I would
>>> only use VMS mailboxes (or Windows pipes or
>>> *nix unix sockets) to buffer hundreds or a
>>> few thousands of messages.
>>>
>>> If I needed hundreds of thousands or
>>> millions I would look for a message queue
>>> (and if I needed billions I would look at
>>> Kafka).
>>
>> Isn't the normal way to use a VMS mailbox as an on-line interface
>> between one (or more) senders and one recevier? That is, the
>> mailbox as such is never intended to "store" anything apart from
>> a very short time during the transmission.
>>
>> If the intention is to buffer 10000's or 100000's of messages,
>> VMS mailboxes looks as the wrong tool from the toolbox...
> 
> Yes. That was sort of my point.
> 
> But if the writer is not blocking and the reader is
> slower than the writer then some messages can queue up.
> 
> Arne

Right. But now, I didn't really understood the original question.
I thought that, in a normal setup, and if the "reader" stops reading
from the queue, the writer can rather quickly get into RWMBX (I think
that is the state) where the process i blocked due to a "full mailbox".
And that is *way* before you reach 64K messages.

Where the message is non-critical and a lost message is no big deal, we
write using IO$M_NORSWAIT so that the writer does not go int RWMBX if the
mailbox device is "full". And we also write using IO$M_NOW.

IO$M_NOW — Completes the I/O operation immediately without waiting for
another process to read the mailbox message.

IO$M_NORSWAIT — If the mailbox is full, the I/O operation fails with a
status return of SS$_MBFULL rather than placing the process in resource
wait mode. (We just ignore the SS$_MBFULL return code...)

Jan-Erik.