This is a follow-up to

  https://cygwin.com/pipermail/cygwin/2021-April/248383.html

I'm attaching a test case slightly simpler than the one posted by the OP in that 
thread.  This is a client/server scenario, with non-blocking AF_UNIX datagram 
sockets.  The client writes COUNT messages while the server is playing with his 
toes.  Then the server reads the messages.

If COUNT is too big, the expectation is that the client's sendto call will 
eventually return EAGAIN.  This is what happens on Linux.  On Cygwin, however, 
there is never a sendto error; the program ends when recv fails with EAGAIN, 
indicating that some messages were dropped.

I think what's happening is that WSASendTo is silently dropping messages without 
returning an error.  I guess this is acceptable because of the documented 
unreliability of AF_INET datagram sockets.  But AF_UNIX datagram sockets are 
supposed to be reliable.

I can't think of anything that Cygwin can do about this (but I would love to be 
proven wrong).  My real reason for raising the issue is that, as we recently 
discussed in a different thread, maybe it's time for Cygwin to start using 
native Windows AF_UNIX sockets.  But then we would still have to come up with 
our own implementation of AF_UNIX datagram sockets, and it seems that we can't 
simply use the current implementation.  AFAICT, Mark's suggestion of using 
message queues is the best idea so far.

I'm willing to start working on the switch to native AF_UNIX sockets.  (I'm 
frankly getting bored with working on the pipe implementation, and this doesn't 
really seem like it has much of a future.)  But I'd like to be confident that 
there's a good solution to the datagram problem before I invest too much time in 
this.

Ken