rename current stable linuxthreads to linuxthreads.old to prepare for import of latest glibc version

64 files changed, 14160 insertions, 0 deletions

diff --git a/libpthread/linuxthreads.old/Changes b/libpthread/linuxthreads.old/Changes
new file mode 100644
index 000000000..b213f36c5
--- /dev/null
+++ b/libpthread/linuxthreads.old/Changes
@@ -0,0 +1,85 @@
+Release 0.9:
+- more ports (SH, IA-64, s390)
+- many bug fixes
+- timed sync object wait functions
+- barrier implementation
+- spinlocks implementation
+- thread register on x86
+- variable stack size and position on some platforms
+
+Release 0.8:
+(ehmm, forgot to update, don't know anymore)
+
+Release 0.7:
+- Destructors for thread-specific data now conform to the POSIX semantics
+  (call destructors again if non-NULL TSD remains after a round of
+   destruction).
+- Implemented thread-specific data as a sparse array, allows more TSD keys
+  and smaller thread descriptors (Ulrich Drepper).
+- Added "error checking" mutexes.
+- Protect against multiple sigwait() on the same signals.
+- Simplified implementation of semaphores when compare_and_swap is
+  not available.
+- Fixed bug in fork() where stdin was closed if fork() was called before
+  the first pthread_create().
+- Fixed bug in the gethostby*_r functions (bad result if null bytes
+  in addresses).
+- Typos in manual pages corrected.
+- First cut at a PowerPC port (not working yet, runs into problems
+  with gcc and with the C library).
+
+Release 0.6:
+- Validation of thread identifiers: no more crashes when operating on
+  a thread that has exited (based on Pavel Krauz's ideas).
+- Added fallback implementation of semaphores for the 386 and the
+  Sparc.
+- Fixed a bug in signal handling causing false restarts of suspended
+  threads.
+- Fixed a bug in realtime scheduling causing all threads to have
+  default scheduling on Ix86 with libc5.
+- With realtime scheduling, unlocking a mutex now restarts the
+  highest priority thread waiting on the mutex, not the
+  first-suspended thread (Richard Neitzel).
+- Timing a process now returns cumulative times for all threads, not
+  just times for the initial thread (suggested by Wolfram Gloger).
+- Cleaned up name space (internal defs prefixed by __, weak aliases
+  for non-portable extensions).
+- MIPS port (contributed by Ralf Baechle).
+
+Release 0.5:
+- Signal-safe semaphores a la POSIX 1003.1b added.
+- Locking bug in pthread_mutex_trylock over recursive mutexes fixed.
+- Race conditions in thread cancellation fixed.
+- Sparc port (contributed by Miguel de Icaza).
+- Support for getpwnam_r and getpwuid_r.
+- Added pthread_kill_other_threads_np to be used in conjunction with
+  exec*().
+
+Release 0.4:
+- Manual pages for all functions.
+- Synchronization bug causing accumulation of zombie processes fixed.
+- Race condition in pthread_cond_timedwait fixed.
+- Recursive mutexes are back by popular demand.
+- Partial support for realtime scheduling (initiated by Richard Neitzel).
+- pthread.h cleaned up a lot: now C++ compatible, added missing "const"
+  qualifiers, added short documentation, put to GNU libc standards
+  for name space pollution (Ulrich Drepper).
+- Motorola 68k port (contributed by Andreas Schwab).
+- Interaction with fork(2) cleaned up a lot.
+
+Release 0.3:
+- Thread creation and reclaimation now performed by a centralized
+  "thread manager" thread.
+- Removed recursive mutexes to make regular mutexes more efficient.
+- Now available as a shared library (contributed by Richard Henderson).
+- Alpha port (contributed by Richard Henderson).
+- Fixed many small discrepancies with Posix 1003.1c.
+- Put under the LGPL instead of the GPL.
+
+Release 0.2:
+- Reentrant libc functions (adapted from libc 5.3.9 by Peeter Joot)
+- pthread_cond_wait did not reacquire the mutex correctly on return
+- More efficient pthread_cond_broadcast
+
+Release 0.1:
+- First public release
diff --git a/libpthread/linuxthreads.old/FAQ.html b/libpthread/linuxthreads.old/FAQ.html
new file mode 100644
index 000000000..21be33ec4
--- /dev/null
+++ b/libpthread/linuxthreads.old/FAQ.html
@@ -0,0 +1,1039 @@
+<HTML>
+<HEAD>
+<TITLE>LinuxThreads Frequently Asked Questions</TITLE>
+</HEAD>
+<BODY>
+<H1 ALIGN=center>LinuxThreads Frequently Asked Questions <BR>
+                 (with answers)</H1>
+<H2 ALIGN=center>[For LinuxThreads version 0.8]</H2>
+
+<HR><P>
+
+<A HREF="#A">A. The big picture</A><BR>
+<A HREF="#B">B. Getting more information</A><BR>
+<A HREF="#C">C. Issues related to the C library</A><BR>
+<A HREF="#D">D. Problems, weird behaviors, potential bugs</A><BR>
+<A HREF="#E">E. Missing functions, wrong types, etc</A><BR>
+<A HREF="#F">F. C++ issues</A><BR>
+<A HREF="#G">G. Debugging LinuxThreads programs</A><BR>
+<A HREF="#H">H. Compiling multithreaded code; errno madness</A><BR>
+<A HREF="#I">I. X-Windows and other libraries</A><BR>
+<A HREF="#J">J. Signals and threads</A><BR>
+<A HREF="#K">K. Internals of LinuxThreads</A><P>
+
+<HR>
+<P>
+
+<H2><A NAME="A">A. The big picture</A></H2>
+
+<H4><A NAME="A.1">A.1: What is LinuxThreads?</A></H4>
+
+LinuxThreads is a Linux library for multi-threaded programming.
+It implements the Posix 1003.1c API (Application Programming
+Interface) for threads.  It runs on any Linux system with kernel 2.0.0
+or more recent, and a suitable C library (see section <A HREF="C">C</A>).
+<P>
+
+<H4><A NAME="A.2">A.2: What are threads?</A></H4>
+
+A thread is a sequential flow of control through a program.
+Multi-threaded programming is, thus, a form of parallel programming
+where several threads of control are executing concurrently in the
+program.  All threads execute in the same memory space, and can
+therefore work concurrently on shared data.<P>
+
+Multi-threaded programming differs from Unix-style multi-processing in
+that all threads share the same memory space (and a few other system
+resources, such as file descriptors), instead of running in their own
+memory space as is the case with Unix processes.<P>
+
+Threads are useful for two reasons.  First, they allow a program to
+exploit multi-processor machines: the threads can run in parallel on
+several processors, allowing a single program to divide its work
+between several processors, thus running faster than a single-threaded
+program, which runs on only one processor at a time.  Second, some
+programs are best expressed as several threads of control that
+communicate together, rather than as one big monolithic sequential
+program.  Examples include server programs, overlapping asynchronous
+I/O, and graphical user interfaces.<P>
+
+<H4><A NAME="A.3">A.3: What is POSIX 1003.1c?</A></H4>
+
+It's an API for multi-threaded programming standardized by IEEE as
+part of the POSIX standards.  Most Unix vendors have endorsed the
+POSIX 1003.1c standard.  Implementations of the 1003.1c API are
+already available under Sun Solaris 2.5, Digital Unix 4.0,
+Silicon Graphics IRIX 6, and should soon be available from other
+vendors such as IBM and HP.  More generally, the 1003.1c API is
+replacing relatively quickly the proprietary threads library that were
+developed previously under Unix, such as Mach cthreads, Solaris
+threads, and IRIX sprocs.  Thus, multithreaded programs using the
+1003.1c API are likely to run unchanged on a wide variety of Unix
+platforms.<P>
+
+<H4><A NAME="A.4">A.4: What is the status of LinuxThreads?</A></H4>
+
+LinuxThreads implements almost all of Posix 1003.1c, as well as a few
+extensions.  The only part of LinuxThreads that does not conform yet
+to Posix is signal handling (see section <A HREF="#J">J</A>).  Apart
+from the signal stuff, all the Posix 1003.1c base functionality,
+as well as a number of optional extensions, are provided and conform
+to the standard (to the best of my knowledge).
+The signal stuff is hard to get right, at least without special kernel
+support, and while I'm definitely looking at ways to implement the
+Posix behavior for signals, this might take a long time before it's
+completed.<P>
+
+<H4><A NAME="A.5">A.5: How stable is LinuxThreads?</A></H4>
+
+The basic functionality (thread creation and termination, mutexes,
+conditions, semaphores) is very stable.  Several industrial-strength
+programs, such as the AOL multithreaded Web server, use LinuxThreads
+and seem quite happy about it.  There used to be some rough edges in
+the LinuxThreads / C library interface with libc 5, but glibc 2
+fixes all of those problems and is now the standard C library on major
+Linux distributions (see section <A HREF="#C">C</A>). <P>
+
+<HR>
+<P>
+
+<H2><A NAME="B">B.  Getting more information</A></H2>
+
+<H4><A NAME="B.1">B.1: What are good books and other sources of
+information on POSIX threads?</A></H4>
+
+The FAQ for comp.programming.threads lists several books:
+<A HREF="http://www.serpentine.com/~bos/threads-faq/">http://www.serpentine.com/~bos/threads-faq/</A>.<P>
+
+There are also some online tutorials. Follow the links from the
+LinuxThreads web page:
+<A HREF="http://pauillac.inria.fr/~xleroy/linuxthreads">http://pauillac.inria.fr/~xleroy/linuxthreads</A>.<P>
+
+<H4><A NAME="B.2">B.2: I'd like to be informed of future developments on
+LinuxThreads. Is there a mailing list for this purpose?</A></H4>
+
+I post LinuxThreads-related announcements on the newsgroup
+<A HREF="news:comp.os.linux.announce">comp.os.linux.announce</A>,
+and also on the mailing list
+<code>linux-threads@magenet.com</code>.
+You can subscribe to the latter by writing
+<A HREF="mailto:majordomo@magenet.com">majordomo@magenet.com</A>.<P>
+
+<H4><A NAME="B.3">B.3: What are good places for discussing
+LinuxThreads?</A></H4>
+
+For questions about programming with POSIX threads in general, use
+the newsgroup
+<A HREF="news:comp.programming.threads">comp.programming.threads</A>.
+Be sure you read the
+<A HREF="http://www.serpentine.com/~bos/threads-faq/">FAQ</A>
+for this group before you post.<P>
+
+For Linux-specific questions, use
+<A
+HREF="news:comp.os.linux.development.apps">comp.os.linux.development.apps</A>
+and <A
+HREF="news:comp.os.linux.development.kernel">comp.os.linux.development.kernel</A>.
+The latter is especially appropriate for questions relative to the
+interface between the kernel and LinuxThreads.<P>
+
+<H4><A NAME="B.4">B.4: How should I report a possible bug in
+LinuxThreads?</A></H4>
+
+If you're using glibc 2, the best way by far is to use the
+<code>glibcbug</code> script to mail a bug report to the glibc
+maintainers. <P>
+
+If you're using an older libc, or don't have the <code>glibcbug</code>
+script on your machine, then e-mail me directly
+(<code>Xavier.Leroy@inria.fr</code>).  <P>
+
+In both cases, before sending the bug report, make sure that it is not 
+addressed already in this FAQ.  Also, try to send a short program that
+reproduces the weird behavior you observed. <P>
+
+<H4><A NAME="B.5">B.5: I'd like to read the POSIX 1003.1c standard. Is
+it available online?</A></H4>
+
+Unfortunately, no.  POSIX standards are copyrighted by IEEE, and
+IEEE does not distribute them freely.  You can buy paper copies from
+IEEE, but the price is fairly high ($120 or so). If you disagree with
+this policy and you're an IEEE member, be sure to let them know.<P>
+
+On the other hand, you probably don't want to read the standard.  It's
+very hard to read, written in standard-ese, and targeted to
+implementors who already know threads inside-out.  A good book on
+POSIX threads provides the same information in a much more readable form.
+I can personally recommend Dave Butenhof's book, <CITE>Programming
+with POSIX threads</CITE> (Addison-Wesley). Butenhof was part of the
+POSIX committee and also designed the Digital Unix implementations of
+POSIX threads, and it shows.<P>
+
+Another good source of information is the X/Open Group Single Unix
+specification which is available both
+<A HREF="http://www.rdg.opengroup.org/onlinepubs/7908799/index.html">on-line</A>
+and as a
+<A HREF="http://www.UNIX-systems.org/gosolo2/">book and CD/ROM</A>.
+That specification includes pretty much all the POSIX standards,
+including 1003.1c, with some extensions and clarifications.<P>
+
+<HR>
+<P>
+
+<H2><A NAME="C">C.  Issues related to the C library</A></H2>
+
+<H4><A NAME="C.1">C.1: Which version of the C library should I use
+with LinuxThreads?</A></H4>
+
+The best choice by far is glibc 2, a.k.a. libc 6.  It offers very good
+support for multi-threading, and LinuxThreads has been closely
+integrated with glibc 2.  The glibc 2 distribution contains the
+sources of a specially adapted version of LinuxThreads.<P>
+
+glibc 2 comes preinstalled as the default C library on several Linux
+distributions, such as RedHat 5 and up, and Debian 2.
+Those distributions include the version of LinuxThreads matching
+glibc 2.<P>
+
+<H4><A NAME="C.2">C.2: My system has libc 5 preinstalled, not glibc
+2.  Can I still use LinuxThreads?</H4>
+
+Yes, but you're likely to run into some problems, as libc 5 only
+offers minimal support for threads and contains some bugs that affect
+multithreaded programs. <P>
+
+The versions of libc 5 that work best with LinuxThreads are
+libc 5.2.18 on the one hand, and libc 5.4.12 or later on the other hand.
+Avoid 5.3.12 and 5.4.7: these have problems with the per-thread errno
+variable. <P>
+
+<H4><A NAME="C.3">C.3: So, should I switch to glibc 2, or stay with a
+recent libc 5?</A></H4>
+
+I'd recommend you switch to glibc 2.  Even for single-threaded
+programs, glibc 2 is more solid and more standard-conformant than libc
+5.  And the shortcomings of libc 5 almost preclude any serious
+multi-threaded programming.<P>
+
+Switching an already installed
+system from libc 5 to glibc 2 is not completely straightforward.
+See the <A HREF="http://sunsite.unc.edu/LDP/HOWTO/Glibc2-HOWTO.html">Glibc2
+HOWTO</A> for more information.  Much easier is (re-)installing a
+Linux distribution based on glibc 2, such as RedHat 6.<P>
+
+<H4><A NAME="C.4">C.4: Where can I find glibc 2 and the version of
+LinuxThreads that goes with it?</A></H4>
+
+On <code>prep.ai.mit.edu</code> and its many, many mirrors around the world.
+See <A
+HREF="http://www.gnu.org/order/ftp.html">http://www.gnu.org/order/ftp.html</A>
+for a list of mirrors.<P>
+
+<H4><A NAME="C.5">C.5: Where can I find libc 5 and the version of
+LinuxThreads that goes with it?</A></H4>
+
+For libc 5, see <A HREF="ftp://sunsite.unc.edu/pub/Linux/devel/GCC/"><code>ftp://sunsite.unc.edu/pub/Linux/devel/GCC/</code></A>.<P>
+
+For the libc 5 version of LinuxThreads, see
+<A HREF="ftp://ftp.inria.fr/INRIA/Projects/cristal/Xavier.Leroy/linuxthreads/">ftp://ftp.inria.fr/INRIA/Projects/cristal/Xavier.Leroy/linuxthreads/</A>.<P>
+
+<H4><A NAME="C.6">C.6: How can I recompile the glibc 2 version of the
+LinuxThreads sources?</A></H4>
+
+You must transfer the whole glibc sources, then drop the LinuxThreads
+sources in the <code>linuxthreads/</code> subdirectory, then recompile
+glibc as a whole.  There are now too many inter-dependencies between
+LinuxThreads and glibc 2 to allow separate re-compilation of LinuxThreads.
+<P>
+
+<H4><A NAME="C.7">C.7: What is the correspondence between LinuxThreads 
+version numbers, libc version numbers, and RedHat version
+numbers?</A></H4>
+
+Here is a summary. (Information on Linux distributions other than
+RedHat are welcome.)<P>
+
+<TABLE>
+<TR><TD>LinuxThreads </TD> <TD>C library</TD> <TD>RedHat</TD></TR>
+<TR><TD>0.7, 0.71 (for libc 5)</TD> <TD>libc 5.x</TD> <TD>RH 4.2</TD></TR>
+<TR><TD>0.7, 0.71 (for glibc 2)</TD> <TD>glibc 2.0.x</TD> <TD>RH 5.x</TD></TR>
+<TR><TD>0.8</TD> <TD>glibc 2.1.1</TD> <TD>RH 6.0</TD></TR>
+<TR><TD>0.8</TD> <TD>glibc 2.1.2</TD> <TD>not yet released</TD></TR>
+</TABLE>
+<P>
+
+<HR>
+<P>
+
+<H2><A NAME="D">D. Problems, weird behaviors, potential bugs</A></H2>
+
+<H4><A NAME="D.1">D.1: When I compile LinuxThreads, I run into problems in
+file <code>libc_r/dirent.c</code></A></H4>
+
+You probably mean:
+<PRE>
+        libc_r/dirent.c:94: structure has no member named `dd_lock'
+</PRE>
+I haven't actually seen this problem, but several users reported it.
+My understanding is that something is wrong in the include files of
+your Linux installation (<code>/usr/include/*</code>). Make sure
+you're using a supported version of the libc 5 library. (See question <A
+HREF="#C.2">C.2</A>).<P>
+
+<H4><A NAME="D.2">D.2: When I compile LinuxThreads, I run into problems with
+<CODE>/usr/include/sched.h</CODE>: there are several occurrences of
+<CODE>_p</CODE> that the C compiler does not understand</A></H4>
+
+Yes, <CODE>/usr/include/sched.h</CODE> that comes with libc 5.3.12 is broken.
+Replace it with the <code>sched.h</code> file contained in the
+LinuxThreads distribution.  But really you should not be using libc
+5.3.12 with LinuxThreads! (See question <A HREF="#C.2">C.1</A>.)<P>
+
+<H4><A NAME="D.3">D.3: My program does <CODE>fdopen()</CODE> on a file
+descriptor opened on a pipe.  When I link it with LinuxThreads,
+<CODE>fdopen()</CODE> always returns NULL!</A></H4>
+
+You're using one of the buggy versions of libc (5.3.12, 5.4.7., etc).
+See question <A HREF="#C.1">C.1</A> above.<P>
+
+<H4><A NAME="D.4">D.4: My program creates a lot of threads, and after
+a while <CODE>pthread_create()</CODE> no longer returns!</A></H4>
+
+This is known bug in the version of LinuxThreads that comes with glibc
+2.1.1.  An upgrade to 2.1.2 is recommended. <P>
+
+<H4><A NAME="D.5">D.5: When I'm running a program that creates N
+threads, <code>top</code> or <code>ps</code>
+display N+2 processes that are running my