[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New class of receive error
In article <15289.1526216143%jinx.noi.kre.to@localhost>,
Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
> Date: Sun, 13 May 2018 07:24:37 -0400
> From: Jason Thorpe <thorpej%me.com@localhost>
> Message-ID: <AB39E25C-2DDA-40FE-A4A8-4A5EDEBEDBC8%me.com@localhost>
> | I think a perfectly reasonable solution to our current dilemma is to
> | ENOBUFS behavior changed to opt-in with a socket option.
>If I had to guess, my assumption would be that Roy is resisting this, as it
>would add (another?) NetBSD specific piece of code in dhcpcd where
>he would (might) prefer to reduce the number of special cases.
>With that in mind, I would not be too upset if a new option as suggested
>was added, which defaulted to off on UDP and unix domain sockets, but
>defaulted to on for the routing socket (and if we ever get it, its clone, the
That magical behavior is desirable from the DTRT perspective, but undesirable
from the consistency and explainability perspective. Doesn't the routing
socket know it has lost a message when the sequence number has a gap?
I am all for the opt-in behavior.
Main Index |
Thread Index |