Problems with the (new) implementation of AF_UNIX datagram sockets

[Corinna Vinschen]

On Apr 15 16:50, Mark Geisert wrote:
> Ken Brown wrote:
> > 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:
> > > > [...]
> > > > > 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.
> 
> Sending datagrams between processes on the same system could be thought of
> as similar to sending/receiving messages on a POSIX message queue.  Though
> the mq_* man pages make it seem like mqs are intended for within-process
> messaging.  But if a datagram receiver created a message queue that datagram
> senders could open, couldn't that provide buffering and allow multiple
> clients?  Kindly ignore if insane.

Interesting idea, actually.  Message queues already implement a lot of
what a unix socket needs in terms of sending/receiving data.  The pipe
would only be needed for credential and descriptor passing, ultimately :)



Corinna