From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 01:08:24 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 6D9D916A4CE for ; Wed, 11 Feb 2004 01:08:24 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0934843D1D for ; Wed, 11 Feb 2004 01:08:24 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 77171 invoked from network); 11 Feb 2004 09:08:22 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 11 Feb 2004 09:08:22 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 11 Feb 2004 03:08:21 -0600 (CST) From: Mike Silbersack To: Andrew In-Reply-To: <20040210111013.G56192-100000@starbug.ugh.net.au> Message-ID: <20040211030445.A1798@odysseus.silby.com> References: <20040210111013.G56192-100000@starbug.ugh.net.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 09:08:24 -0000 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. Mike "Silby" Silbersack