Date: 05 Dec 2000 16:30:26 -0500 From: Randell Jesup <rjesup@wgate.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Terry Lambert <tlambert@primenet.com>, Bosko Milekic <bmilekic@technokratis.com>, arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <ybuelzmpnd9.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Alfred Perlstein's message of "Mon, 4 Dec 2000 16:26:59 -0800" References: <Pine.BSF.4.21.0012031808540.98531-100000@jehovah.technokratis.com> <200012042352.QAA12392@usr02.primenet.com> <20001204162015.A8051@fw.wintelcom.net> <20001204162659.B8051@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein <bright@wintelcom.net> writes:
>> Well behaved applications (read: written by me) deal with errors
>> like ENOBUFS properly, what they do is close the socket and
>> commence throttling connections.
Most user-level applications do not. Certainly most applications
that call write() don't.
In fact, a grep of /usr/src shows that of things outside of sys,
only a handful test for ENOBUFS: telnet, sendmail, ipfilter, ntp, natd,
and ping seem to include a test (I didn't check what they do with it
though).
>> I would not want my process to be stuck in the kernel waiting
>> for bufferspace that could take quite a long time get ahold of.
In many cases you do. How different is that than waiting on some
other resource that may take a long time, or getting a response to a
write or read across a network? In fact, I'd assert in most cases waiting
is the appropriate action unless a call is non-blocking.
Given the very small number of programs that _do_ handle ENOBUFS,
I'd assert that the default action should be to wait, unless the
application has said it wants to hear about them.
>> However I can understand someone wanting a niave process not
>> to get such errors because they may misbehave and do stupid
>> things like busy loop or just abort entirely.
or fail a complex transaction, etc. Like 99% of user code out
there when faced with ENOBUFS.
>> Perhaps adding a per-process or per-socket or per-something flag
>> to ask for indefinite blocking (or turn it off) would be a good
>> idea, honestly having it one way or the other isn't very good
>> depending on your application. I can live with the current
>> situation so I'll leave 'fixing' this to someone who wants
>> the indefinite blocking.
per-socket makes sense; or keyed off non-blocking mode. The
default should be wait.
>> Oh, and don't forget, you can't block me indefinitely if I'm
>> writing to a non-blocking socket. In fact if M_WAIT is set
>> I shouldn't be blocking at all on a non-blocking socket.
Agreed; even more reason to tie it to non-blocking mode.
>One more thing, ENOBUFS is indicative of a misconfiguration and
>shouldn't happen in day to day operations, if it does happen then
>the user needs to reconfigure for more buffer space.
Or it's indicative of a DoS attack (possibly unintentional), or
a load problem, possibly temporary. I dislike arbitrary tuning parameters.
Generally they're either ignored (mostly), or set wildly high in the hope
of the annoyance someone hit once going away. Or just set randomly. Most
of the people doing the setting don't have a good grasp of why it should be
set to a specific value. Kind of like putting a spark-advance knob on
the steering wheel (which they once did, believe it or not).
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybuelzmpnd9.fsf>