GNU C Library Version 2.3
Ulrich Drepper
Red Hat, Inc.
drepper@redhat.com
May 2, 2002
Abstract
The next major release of the GNU C library will be 2.3 which marks the
beginning of a new phase of the development of the project. The level of
functionality and standard compliance of other C libraries in the industry was
reached or even surpassed. The main aspects of development today is to fix
holes in the implementations (and standards) and optimization. The paper will
introduce what is done in these two areas.
1 Preface
Version 2.3 of the GNU C Library is the beginning of
a new phase of the development. Up to version 2.2 the
main objective was to catch up with existing standards
and industry practice. Since the implementation was not
yet finished a lot of optimizations were not implemented.
With the next release all this changes. First, additions to
the library go beyond what standards describe. Features
users requested and which are found necessary in other
projects were implemented. Additionally extensive op-
timizations of the runtime environment were performed
and implemented with the result that program execution
can be much faster.
The following text will first introduce the new features
and then describe the various optimizations performed.
Some of the optimization techniques are not only appli-
cable to the C library. They are useful for all ELF shared
libraries.
2 New Features
The number of new features the new release provides is
high again. Not all of them can be explained here in great
detail. We will limit the description of these features to a
general overview. The next section will describe the most
important new features in detail.
2.1 Thread-local Locale Model
The locale model in the ISO C and POSIX standard was
designed in simpler times. Computers were often not
connected or only connected locally which normally meant
that all users of the computers are using is the same lo-
cale. Computers at different sites use different locales but
at any one site there are normally no differences.
This all changed with the advent of globally connected
machines with the help of the Internet. Suddenly one
machine could service clients from all over the world
with widely different requirements on the locales. These
service programs are often written in a way that allows
servicing multiple clients from one process (e.g., using
threads).
To enable such programming it is necessary to allow the
use of more than one locale at the same time in the same
process. This is not possible in the moment. Switching
between global locales using setlocale is not practi-
cal since this would have to happen before every single
use of the locale (even for often used functions like iss-
pace). In a multi-threaded process the setlocale call
and the following use must be protected using a critical
region which effectively reduces the process to serialize
the threads for a large part of the time. When no threads
are used the synchronization is easier but the costs are
still prohibitively high. A different solution is needed.
Another source of problems is the need of the ISO C++ li-
brary implementation. The ISO C++ library implements
locales as objects. This is not surprising and by itself
no problem. But it is also required that locale objects
can be constructed based on named POSIX locales. I.e.,
the functionality the C++ standard defines which is also
available in ISO C must be implemented based on the
C locale content. For instance, the tolower member
function of the ctype facet of the C++ locale must pro-
duce the same result as a call to the tolower C function.
A partly complete solution for these problems has existed
for quite some time in glibc. The 2.1 version of the GNU
C library introduced the concept of locale objects with