Re: Problems with the (new) implementation of AF_UNIX datagram sockets

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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?


Corinna