Re: Allowing multiple threads packages, a new threads package

[Roland McGrath <roland at frob dot com>]

An important distinction may not be clearly understood from what Ulrich said.

The details like lock sizes are not part of the general libc ABI.  That is
why the <bits/libc-lock.h> declarations can be opaque in the !_LIBC case.
The only visible parts of the ABI that have locks, like libio's FILE, use
indirection so that the type and size of the lock data structure are not
exposed in the ABI.  

Those details are only part of the "internal" ABI between libc and libpthread.

As Ulrich pointed out, libc internally is intentionally quite portable to
different locking implementations at the source level.  You could very well
write a different bits/libc-lock.h variant and build a libc with that.  If
done properly, the resulting libc.so.6 would be completely compatible with
the existing ABI used by programs that use only libc--it's just
incompatible with the existing glibc's libpthread.so.0 binary and any
programs that require it.

It would be straightforward to write a variant bits/libc-lock.h that uses a
level of indirection and relies on explicit initialization via the shared
library initializer.  It would be simple to make a variant libpthread that
works with this and does the necessary allocation and initialization.  Then
you would be able to build your own variant glibc that is wholly compatible
with the existing libc.so.6 and libpthread.so.0 ABIs, but can also be used
with a different pthread implementation instead.  Ulrich objects to making
the default glibc use indirection and explicit initialization (and probably
rightly so).  So people would have to install your variant glibc package
instead of the normal one, and pay that overhead when they use libpthread,
to also be able to use your alternative thread library for glibc's internal
locks.

Now that I think about it, I think this is so simple to do that I will
experiment with it a little myself.