AF_UNIX/SOCK_DGRAM is dropping messages

[Ken Brown]

n 3/31/2021 11:07 AM, Ken Brown via Cygwin wrote:
> On 3/31/2021 4:24 AM, sten.kristian.ivarsson@gmail.com wrote:
>> [snip]
>>>>>> Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems to drop
>>>>>> messages or at least they are not received in the same order they
>>>>>> are  sent
>>
>> [snip]
>>
>>> Thanks for the test case.  I can confirm the problem.  I'm not familiar enough
>>> with the current AF_UNIX implementation to debug this easily.  I'd rather
>>> spend my time on the new implementation (on the topic/af_unix branch).  It
>>> turns out that your test case fails there too, but in a completely different 
>>> way,
>>> due to a bug in sendto for datagrams.  I'll see if I can fix that bug and 
>>> then try
>>> again.
>>>
>>> Ken
>>
>> Ok, too bad it wasn't our own code base but good that the "mystery" is verified
>>
>> I finally succeed to build topic/af_unix (after finding out what version of 
>> zlib was needed), but not with -D__WITH_AF_UNIX to CXXFLAGS though and thus I 
>> haven’t tested it yet
>>
>> Is it sufficient to add the define to the "main" Makefile or do you have to 
>> add it to all the Makefile:s ? I guess I can find out though
> 
> I do it on the configure line, like this:
> 
>   ../af_unix/configure CXXFLAGS="-g -O0 -D__WITH_AF_UNIX" --prefix=...
> 
>> Is topic/af_unix fairly up to date with master branch ?
> 
> Yes, I periodically cherry-pick commits from master to topic/af_unix.  I'lldo 
> that again right now.
> 
>> Either way, I'll be glad to help out testing topic/af_unix
> 
> Thanks!

I've now pushed a fix for that sendto bug, and your test case runs without error 
on the topic/af_unix branch.

By the way, I think the implementation of sendto/recv for datagrams is very 
inefficient when there are repeated calls to sendto as in your test case. 
Nevertheless, your test case actually runs slightly faster on the topic/af_unix 
branch than it does on master (when the latter succeeds, which it does about 
half the time for me).  So I'm not sure whether it's worth worrying about this.

Here's the issue, briefly.  The communication is done via a Windows named pipe. 
  The receiver creates the pipe when it creates and binds its socket.  It 
creates only one pipe instance.  The sender connects to the pipe, writes, and 
closes its handle.  But the pipe is not available for another sender to connect 
to until the receiver reads the message, after which it disconnects the sender.

Ken