A [new version of GLIBC which supports NPTL](http://lists.debian.org/debian-glibc/2003/debian-glibc-200310/msg00063.html) is now available from the experimental repository for Debian. It’s so strange to see only one process reported for nautilus or mozilla now… but pleasant.
I’m looking forward to doing more extensive tests on the new threading implementation, with a multithreaded mail server I do a few bits and pieces with from time to time. General scalability comparisons with a 2.4 kernel would be interesting, especially since I consider 2.4 threading to suck. As it stands, Solaris is by far the most capable and used platform on which to run threaded applications. It was one of Linux’s big disadvantages up until now. Along with a slightly light-hearted implementation of NFS when used for enterprise-level purposes.
There were one or two problems on the way to getting the new GLIBC up and running. Firstly, _iconv -l_ would report that it could only convert between a small number of character sets. Solution? Get a copy of _/usr/lib/gconv/gconv-modules_ from another Linux box, as it appears to be missing from libc6 package 2.3.2.dsl-1. This makes _gnome-terminal_ and _nautilus_ work again.
Also, djbdns and daemontools use _extern int errno_ instead of _#include <errno.h>_, which causes them to fail at runtime (for previously-compiled binaries), or at compile-time (if attempting to compile against the latest libc headers). One just has to change one line in _error.h_, recompile, and it’ll work. I can see this issue causing breakage for a lot more applications though…
NPTL will make such a difference anyway—core dumps which have information from all threads! Proper POSIX signal handling! One PID for the whole process! Not to mention the huge improvements in speed over the old linuxthreads implementation.