This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libc-alpha] Re: horrible disk thorughput on itanium


> From: Andreas Jaeger <aj@suse.de>
> Date: Sat, 08 Dec 2001 08:38:42 +0100

> > In a single-threaded application, compiled without _REENTRANT, can't
> > putc() just be a *macro* in the header file that calls putc_unlocked()?
> > This solves the problem for newly recompiled code.
> 
> It could be - but then we would break lots of stuff (most people
> forget about _REENTRANT) and every library has to be build with
> _REENTRANT so that the library is thread-safe :-(

Fair enough, but how about having an easy way for people to get decent
unithreaded performance without having to rewrite all their code?  We
could introduce a feature-test macro called _NONREENTRANT, say.  This
would be like Solaris, except that the default would be reentrant
instead of nonreentrant.  So this wouldn't affect existing glibc
behavior.

_NONREENTRANT would make it a lot easier to spruce up unithreaded GNU
apps.  Maintainers could just prepend '#define _NONREENTRANT 1' to
their source, or put this into their configure.in files:

AC_DEFINE(_NONREENTRANT, 1, [This makes glibc faster for unithreaded code.])


Under the current regime, in contrast, maintainers have to do all
sorts of code contortion to make unithreaded stdio work fast with
glibc.  There are easily 300 lines of code devoted to this problem
just in GNU diffutils, for example.  Lots of maintainers don't bother
with this gorp, and the resulting horrible performance makes glibc
look bad.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]