Re: ping: sendto: No buffer space available

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sun, 9 Oct 2011 17:36:06 -0700
Erik Fair <fair%netbsd.org@localhost> wrote:

> On second thought, the kernel should block on that condition, unless the 
> user code has explicitly set a non-blocking flag (and thus indicated its 
> ability/willingness to handle the "queue is full" error with appropriate 
> behavior). Otherwise, we're simply going to get naive application code 
> that bangs away at sending without appropriate exponential backoff.
> 
> Yes, this is an API change. Alternative suggestions welcome.

In general, I expect write(2)/sendmsg(2)/friends to error on EINTR and
need to be restarted, or EAGAIN in non-blocking mode, or to report a
short byte count, but it's legitimate to drop the connection if more
serious errors occur.  Should ENOBUFS be considered like EAGAIN and
always be considered restartable/recoverable?  The current difference
is that in non-blocking mode EAGAIN would not occur, the socket would
block.  Then it'd also make sense to me to block in blocking mode for
ENOBUFS like you suggest.  In non-blocking mode, should it however
still error with ENOBUFS?  Why not EAGAIN then?

Of course, in non-blocking mode and with polling, I'd also not expect
spurious POLLOUT events if the next write is about to error with
ENOBUFS, ideally...  This might complicate things if the syscall I/O
layer lacks inside information about the driver's state, though.
-- 
Matt