Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Mar 2004 15:36:46 +1100
From:      Tim Robbins <tjr@freebsd.org>
To:        John Birrell <jb@cimlogic.com.au>
Cc:        cvs-all@freebsd.org
Subject:   Re: cvs commit: src/lib/libc/stdio _flock_stub.c local.h
Message-ID:  <20040309043646.GA89072@cat.robbins.dropbear.id.au>
In-Reply-To: <20040309150536.R234@freebsd3.cimlogic.com.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040309043646.GA89072>