From owner-freebsd-arch Mon Dec 4 16:27:16 2000 From owner-freebsd-arch@FreeBSD.ORG Mon Dec 4 16:27:15 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D18E137B400 for ; Mon, 4 Dec 2000 16:27:14 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB50QxS23578; Mon, 4 Dec 2000 16:26:59 -0800 (PST) Date: Mon, 4 Dec 2000 16:26:59 -0800 From: Alfred Perlstein To: Terry Lambert Cc: Bosko Milekic , arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <20001204162659.B8051@fw.wintelcom.net> References: <200012042352.QAA12392@usr02.primenet.com> <20001204162015.A8051@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001204162015.A8051@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Dec 04, 2000 at 04:20:15PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alfred Perlstein [001204 16:20] wrote: > > Well behaved applications (read: written by me) deal with errors > like ENOBUFS properly, what they do is close the socket and > commence throttling connections. > > 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. > > 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. > > 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. > > 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. 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. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message