[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ping: sendto: No buffer space available
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.
Main Index |
Thread Index |