[Info-vax] Mailbox driver analysis regarding greater than 65535 messages in mailbox

[Hein RMS van den Heuvel]

On Monday, November 30, 2020 at 6:29:44 PM UTC-5, Robert A. Brooks wrote:
> For the most part, the mailbox driver does not base its behaviour on the 
> value in UCB$W_MSGCNT, except for three of checks that will return an error 
> upon a read request if the message count is zero and several other conditions are met. 
:
> With minimal investigation (about an hour, which includes some email conversation), we suspect the proper way to deal with 
> this is to return an error to a writer if the mailbox has 65535 messages and to document this limitation. 

Hmm, as I read the descriptions thusfar applications actually causing there to be more than 64K messages in a mailbox can continue writing more and read them back in order, but cannot get a consistent message count - that part is obvious because of the 16 bit fields to hold and expose the count.
But still they can keep writing and reading peaking above 64K messages only getting a non-success status when the mailbox is empty. Correct?
If so, IMHO that behaviour should not be willingly broken. 
Maybe an alternate success status, but even that could break applications testing for status == SS$_NORMAL.

Promoting the USB to LONG would seems to be a no-brainer.
But when exposing the count via SENSEMODE/IOSB perhaps that count value should just return 65535 when UCB$L_MSGCNT >= 65535 ???

I don't think there is a business case to do anything though. 
Besides the recent C.O.V post, how many requests/concerns have there been thus far?
The recent C.O.V. post suggests a willingness to work-around to split into multiple mailboxes already.
Would multiple mailboxes have the potential for better performance allowing for more parallel activities or is all mailbox access behind a single spinlock anyway?

Now If someone cracks the seal on the mailbox driver anyway, then at least promote the USB counter to long (for V9 only) notably if it also gives better alignment?

Cheers,
Hein