Subject: Re: fixing send(2) semantics (kern/29750)
To: Jonathan Stone <jonathan@dsg.stanford.edu>
From: Emmanuel Dreyfus <manu@netbsd.org>
List: tech-kern
Date: 03/27/2005 08:37:36
Jonathan Stone <jonathan@dsg.stanford.edu> wrote:

> >That's the whole point: if non blocking I/O is set, SUS and our man
> >pages say that we must block instead of failling.
>=20
> I think that should be "unless non-blocking I/O is set..."

Yes, that's what I meant.
=20
> And, if there is insufficient buffer space *IN THE SOCKET LAYER*
> for the kernel to accept the send() request, then sure, we should sleep,
> *in the socket layer*.
>=20
> Whatever happens below the socket layer is protocol-specific; SUS
> doesn't have much to say there.  =20

If you send data too fast for the interface to consume it, you'll never
consume the socket send buffer, you always fill the queue. You get
ENOBUFS, which SUS says you should not get with blocking I/O.

If we consider that what SUS does not talk about what happens in the
link layer, then IMO, we should let the link layer drop packets without
returning ENOBUFS.

--=20
Emmanuel Dreyfus
Un bouquin en fran=E7ais sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org