From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 21:20:12 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 294B416A477 for ; Wed, 11 Jul 2007 21:20:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id 0FC2013C4BB for ; Wed, 11 Jul 2007 21:20:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 11 Jul 2007 14:20:11 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 50A54125A28; Wed, 11 Jul 2007 14:20:11 -0700 (PDT) Message-ID: <469549A0.70102@elischer.org> Date: Wed, 11 Jul 2007 14:20:32 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Matthew Dillon References: <46930106.3040503@gmail.com> <20070710123634.GD1194@britannica.bec.de> <4693C77E.7070806@elischer.org> <200707112114.l6BLERAF061933@apollo.backplane.com> In-Reply-To: <200707112114.l6BLERAF061933@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: add closefrom() call X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 Jul 2007 21:20:12 -0000 Matthew Dillon wrote: > We added it basically because doing all the junk described in > previous postings in this thread in userland is a ridiculously huge > eyesore that doesn't scale and doesn't make sense when 5 minutes of > programming nets you a shiny new system call which does it all for you. > > If you are worried about optimizing it (which kinda implies a system > call anyhow since you aren't doing a context switch for each descriptor), > worry about optimizing the kernel implementation of the system call > rather then optimizing the unoptimizable userland that eats 300ns+ per > descriptor to do the close() instead of the 10ns/descriptor that it > takes the kernel to do the close(). my thought exactly. I also add that speed IS important in this case as I have seen MANY programs that start up by closing the first 2048 descriptors "just in case" and I've seen some that do it more than once as they move through to daemon state. These programs have a slow startp due to this (not to mention it's a pain to step past it all when debugging). Julian > > -Matt