Re: The unreliability of AF_UNIX datagram sockets

[Ken Brown <kbrown@cornell.edu>]

On 5/3/2021 2:40 PM, Corinna Vinschen wrote:
> On May  3 12:56, Ken Brown wrote:
>> On 5/3/2021 11:45 AM, Corinna Vinschen wrote:
>>> 7. The idea of _mq_recv partial reads is entirely broken.  Given that
>>>      the information in the queue consists of header info plus payload,
>>>      the entire block has to be read, and then a new block with fixed
>>>      header and shortened payload has to be rewritten with bumped priority.
>>>      This in turn can only be performed by the AF_UNIX code, unless we
>>>      expect knowledge of the AF_UNIX packet layout in the mqueue code.
>>
>> The partial read is actually OK as is, since it's comparable to what happens
>> on a partial read from a pipe.  I already have AF_UNIX code (on the
>> topic/af_unix branch) that deals with that.  A boolean variable _unread
>> keeps track of whether there's unread data from a previous partial read.  If
>> so, the next read just reads data without expecting a header.
> 
> Ok, never mind.
> 
> One advantage of the mqueue when utilized as above would be that this
> kind of state info is not required.  The content of a packet would
> always be self-contained and bumping the priority would automagically
> move the packet content to the top of the queue.  But that's just
> idle musing at this point.

I thought about that but rejected it for the following reason: Suppose the 
receiver reads a message and tries to rewrite it with modified header, shortened 
payload, and bumped priority.  The sender might have already written more 
messages between the read and the write, and the queue could be full.

Now that I'm rethinking this, however, maybe we could get around that problem 
with an internal _mq_lock function that would block senders while the receiver 
decides whether it needs to do a partial read.

Ken