On Sun, Mar 27, 2005 at 01:34:45PM -0800, Jonathan Stone wrote:
> 
> The technically informed participants seem to have reached consensus
> that there's nothing actively wrong with current send(2) semantics on
> NetBSD.  (I note Thor would prefer to change the ENOBUFS semantics,
> but I haven't noticed him say what we have now is actually incorrect).

Matt Thomas pointed out that my supposition about using a low-water mark
on the send socket buffer was also wrong: output UDP doesn't _use_ the
socket buffer, and even if it did, since the destination address is
per-packet, you couldn't just assume that "the" underlying ifq would
drain, resulting in the socket buffer draining: there might be several
underlying interface queues.

So select() doesn't -- can't -- block if there's "less than the
low-water mark" available with things just as they are now; and it
seems like it ought to be able to.  But select on *what*?  How can
it know which ifq you're trying to feed?  With select(), unlike
with send(), you don't have the destination address available, so
you can't know which ifq to wait for space in!

Something conceptually like selectto() could fix this in a cleaner
way than by letting send() block... but would be nonstandard as well.

This really is a bit of a mess.

Thor