From owner-cvs-src@FreeBSD.ORG Mon Mar 8 20:35:58 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44F6F16A4CE; Mon, 8 Mar 2004 20:35:58 -0800 (PST) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1A8443D2D; Mon, 8 Mar 2004 20:35:57 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.204.98) by smtp01.syd.iprimus.net.au (7.0.024) id 402BA9270082608B; Tue, 9 Mar 2004 15:35:53 +1100 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 6803D4165; Tue, 9 Mar 2004 15:36:46 +1100 (EST) Date: Tue, 9 Mar 2004 15:36:46 +1100 From: Tim Robbins To: John Birrell Message-ID: <20040309043646.GA89072@cat.robbins.dropbear.id.au> References: <200403090245.i292j0a6035728@repoman.freebsd.org> <20040309032248.GA88649@cat.robbins.dropbear.id.au> <20040309143223.Q234@freebsd3.cimlogic.com.au> <20040309035532.GA88825@cat.robbins.dropbear.id.au> <20040309150536.R234@freebsd3.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040309150536.R234@freebsd3.cimlogic.com.au> User-Agent: Mutt/1.4.1i cc: cvs-src@freebsd.org cc: John Birrell cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libc/stdio _flock_stub.c local.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2004 04:35:58 -0000 On Tue, Mar 09, 2004 at 03:05:36PM +1100, John Birrell wrote: > On Tue, Mar 09, 2004 at 02:55:32PM +1100, Tim Robbins wrote: > > My concern here is that we are slowing down critical paths for the > > sake of broken applications that grope around inside FILEs. Why do > > we need to support this? Which applications require it, and why? > > I'm not sure that I agree that applications are 'broken' when they > use things that are defined in the header file along with the FILE > structure itself. They are. The structure is an implementation detail, and the layout or size could change between releases, or it's definition could be moved into a libc-private header entirely. > As I said in my previous mail, if you want to improve performance, > then remove the locking code from libc completely in the single-threaded > case. That will have more benefit than checking a NULL pointer that > has to be resolved anyway in order to access the fields it points > to. Threads are useful. Supporting some phantom application you won't name that initializes its own FILE structures instead of using the correct interfaces is not terribly useful. > I think you're arguing about just a few instructions on i386. I'm arguing over a principle, and trying to stop FreeBSD getting locked into a certain arrangement of stdio internals for the sake of broken applications. Tim