From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 09:48:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C87716A4CE for ; Wed, 11 Feb 2004 09:48:49 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61D7443D1D for ; Wed, 11 Feb 2004 09:48:48 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 24533 invoked from network); 11 Feb 2004 17:48:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.47]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 11 Feb 2004 17:48:47 -0000 Message-ID: <402A6AFF.2020804@freebsd.org> Date: Wed, 11 Feb 2004 18:48:47 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040125 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack References: <20040210111013.G56192-100000@starbug.ugh.net.au> <20040211030445.A1798@odysseus.silby.com> In-Reply-To: <20040211030445.A1798@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Andrew cc: freebsd-hackers@freebsd.org Subject: Re: select, sendto and ENOBUFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2004 17:48:49 -0000 Mike Silbersack wrote: > On Tue, 10 Feb 2004, Andrew wrote: > > >>The conclusion being that send, sendto and select will never block on a >>UDP socket and the man page just doesn't make it too clear. I'm assuming >>it is the same for raw sockets. >> >>UNPv1 section 6.3 seems to say that select should work for UDP...Part 2 >>under "Under What Conditions Is a Descriptor Ready" certainly indicates >>that select should work. >> >>Anyway a bug or not, is there a better work around than sleeping? I'm >>guessing not... >> >>Thanks, >> >>Andrew > > > Well, one workaround would be to figure out a way to have the kernel > implement the behavior you desire. :) > > I doubt that anyone will put effort into this problem soon; it looks like > it would be quite a large change to the network stack, and we all have > plenty of projects to work on. > > Maybe you could figure out where in the kernel the ENOBUFS is occuring, > and then add a tsleep which would be woken when the transmit queue cleared > a bit. That would introduce unexpected blocking, but I can't imagine that > waiting for a few packets to exit the queue would take much time. I traced it down when this topic came up the first time a couple of weeks ago. The ENOBUFS happens at the interface output queue when it is full. You better not put a tsleep in there. -- Andre