Date: Tue, 9 Mar 2004 15:05:36 +1100 From: John Birrell <jb@cimlogic.com.au> To: Tim Robbins <tjr@freebsd.org> Cc: John Birrell <jb@cimlogic.com.au> Subject: Re: cvs commit: src/lib/libc/stdio _flock_stub.c local.h Message-ID: <20040309150536.R234@freebsd3.cimlogic.com.au> In-Reply-To: <20040309035532.GA88825@cat.robbins.dropbear.id.au>; from tjr@freebsd.org on Tue, Mar 09, 2004 at 02:55:32PM %2B1100 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. I think you're arguing about just a few instructions on i386. FWIW, I OpenSSL's file BIO with this functionality. -- John Birrell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040309150536.R234>