Problems with the (new) implementation of AF_UNIX datagram sockets

[Ken Brown]

On 4/15/2021 9:58 AM, Corinna Vinschen wrote:
> On Apr 15 09:16, Ken Brown wrote:
>> On 4/15/2021 7:49 AM, Corinna Vinschen wrote:
>>> On Apr 14 12:15, Ken Brown wrote:
>> [...]
>>>> 1. Writing will block until a connection to the peer's pipe can be
>>>> made.  In particular, if there are two consecutive writes with the
>>>> same peer, the second one will block until the peer reads the
>>>> first message.  This happens because the peer's pipe is not
>>>> available for the second connection until the peer disconnects the
>>>> first connection.  This is currently done in recvmsg,
>>>> and I don't see a straightforward way to do it anywhere else.
>>>
>>> I'm a bit puzzeled.  The idea for datagrams was to call open/send/close
>>> in each invocation of sendmsg.  Therefore the pipe should become
>>> available as soon as the other peer has sent it's data block.  The time
>>> a sendmsg has to wait for the pipe being available should be quite short!
>>
>> Unfortunately, the pipe isn't available until the server disconnects.  I
>> observed this in practice, and it's also documented at
>>
>> https://docs.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-disconnectnamedpipe
>>
>> "The server process must call DisconnectNamedPipe to disconnect a pipe
>> handle from its previous client before the handle can be connected to
>> another client by using the ConnectNamedPipe function."
> 
> d'oh
> 
>> [...]
>>> Another idea might be to implement send/recv on a DGRAM socket a bit
>>> like accept.  Rather than creating a single_instance socket, we create a
>>> max_instance socket as for STREAM socket listeners.  The server side
>>> accepts the connection at recv and immediately opens another pipe
>>> instance, so we always have at least one dangling instance for the next
>>> peer.
>>
>> I thought about that, but you would still have the problem (as in 1 above)
>> that the pipe instance isn't available until recv is called.
> 
> There always is at least one instance.  Do you mean, two clients are
> trying to send while the server is idly playing with his toes?

Yes.  That was essentially the situation in the test case attached to

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

It was actually one client sending many messages while the server was playing 
with his toes, but the effect was the same.

Ken