Re: sleeping instead of ENOBUFS on write to socket?

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Fri, May 27, 2011 at 01:20:04PM -0400, der Mouse wrote:
> > I'm not sure what happens for blocking datagram sockets.
> 
> The historical practice is that they're "best effort": writing never
> blocks.  Some conditions responsible for packet drop are reflected in
> the write()/send()/etc return value; others aren't - though I think for
> AF_LOCAL they're all the former.  Blocking on SOCK_DGRAM matters only
> when trying to read when there's nothing there.
> 
> Is that how it _should_ be?  That's debatable.  But if you make
> SOCK_DGRAM writes block without some kind of explicit request (like a
> setsockopt), you will break a fair bit of code.

Yeah, it's worse than that.  There is at least one widely deployed
implementation out there where AF_LOCAL, SOCK_DGRAM even reorders
datagrams -- "just like real UDP!".  Oh, and sometimes it used to
duplicate them, but I guess that was an unintentional bug.

AF_LOCAL, SOCK_SEQPACKET offers an opportunity to establish reasonable
semantics that would be a lot more useful for many of the users of
local SOCK_DGRAM sockets.  I'm all for it.

What do the SCTP implementations out there in the world use now?  SOCK_DGRAM,
SOCK_SEQPACKET, or something else?  That might be the only other prior
ue of the seqpacket sockets.