On Sun, Mar 27, 2005 at 04:43:24PM -0500, Thor Lancelot Simon wrote:
> 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!

And with multicast, you can have several ifq for a single destination
interface.

> 
> 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.

Sure.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--