In message <1gu2pdo.k9uzf21dwmz96M%manu@netbsd.org>Emmanuel Dreyfus writes
>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.
>>
>> I think that should be "unless non-blocking I/O is set..."
>
>Yes, that's what I meant.
>
>> 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*.
>>
>> Whatever happens below the socket layer is protocol-specific; SUS
>> doesn't have much to say there. 
>
>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.

My quick reading of the SUSve spec for send(2) is that it talks only
about what happens between userspace and the socket layer. What
happens below that is up to the protocol.  Which leads us to:


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

Seems reasonable, and I see that's also one of Jason's responses to
the PR.

OTOH, all evening I have been busily issuing `pings' to try to keep my
wifi alive, fully expecting to see ping -f eventualy return "No buffer
space available".  How long has ping been returning ENOBUFS? Or ttcp -U?
I'd guess 20-odd years.  If the people (all too often also-rans) who
go to standards bodies stupidly mandated no errors for blocking
send()s, is there some way we can preserve traditional BSD
compatibility on a per-process/per-app basis? A setsockopt(), maybe)?


PS: sorry about the high rate of typos.  I have about 30 second
latency right now, I typed this whole line vai touch, none of it has
echoed yet! I suspect the delay is messing up escape sequences and
confusing my editor...

[[ *long* interruption...]]

... and  I hope this isn't hopelessy out-of-date.