From 7814856974388a856a575fa45f88d502c8a1ab29 Mon Sep 17 00:00:00 2001 From: Ulrich Drepper Date: Sun, 12 Sep 1999 19:34:34 +0000 Subject: Update. * posix/fnmatch.c (internal_fnmatch): Make it compilable outside glibc by defining internal_function if it isn't already. --- linuxthreads/FAQ.html | 157 ++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 119 insertions(+), 38 deletions(-) (limited to 'linuxthreads/FAQ.html') diff --git a/linuxthreads/FAQ.html b/linuxthreads/FAQ.html index e0de566c6a..21be33ec4c 100644 --- a/linuxthreads/FAQ.html +++ b/linuxthreads/FAQ.html @@ -73,13 +73,12 @@ platforms.

A.4: What is the status of LinuxThreads?

-In short, it's not completely finished (hence the version numbers in -0.x), but what is done is pretty mature. 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 J). Apart -from the signal stuff, all the Posix 1003.1c base functionality is -provided and conforms to the standard (to the best of my knowledge). +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 @@ -90,11 +89,10 @@ completed.

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 are some rough edges in -the LinuxThreads / C library interface, at least with libc 5, but most -of these rough edges are fixed in glibc 2, which should soon become -the standard C library for Linux distributions (see section C).

+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 C).

@@ -139,12 +137,22 @@ HREF="news:comp.os.linux.development.kernel">comp.os.linux.development.kernel -Very specific LinuxThreads questions, and in particular everything -that looks like a potential bug in LinuxThreads, should be mailed -directly to me (Xavier.Leroy@inria.fr). Before mailing -me, make sure that your question is not answered in this FAQ.

+

B.4: How should I report a possible bug in +LinuxThreads?

+ +If you're using glibc 2, the best way by far is to use the +glibcbug script to mail a bug report to the glibc +maintainers.

+ +If you're using an older libc, or don't have the glibcbug +script on your machine, then e-mail me directly +(Xavier.Leroy@inria.fr).

-

B.4: I'd like to read the POSIX 1003.1c standard. Is +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.

+ +

B.5: I'd like to read the POSIX 1003.1c standard. Is it available online?

Unfortunately, no. POSIX standards are copyrighted by IEEE, and @@ -183,8 +191,8 @@ integrated with glibc 2. The glibc 2 distribution contains the sources of a specially adapted version of LinuxThreads.

glibc 2 comes preinstalled as the default C library on several Linux -distributions, such as RedHat 5.0 and 5.1, and recent beta versions of -Debian. Those distributions include the version of LinuxThreads matching +distributions, such as RedHat 5 and up, and Debian 2. +Those distributions include the version of LinuxThreads matching glibc 2.

C.2: My system has libc 5 preinstalled, not glibc @@ -199,14 +207,6 @@ 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.

-Unfortunately, many popular Linux distributions (e.g. RedHat 4.2) come -with libc 5.3.12 preinstalled -- the one that does not work with -LinuxThreads. Fortunately, you can often find pre-packaged binaries -of more recent versions of libc for these distributions. In the case -of RedHat 4, there is a RPM package for libc-5.4 in the "contrib" -area of RedHat FTP sites. -

-

C.3: So, should I switch to glibc 2, or stay with a recent libc 5?

@@ -219,7 +219,7 @@ Switching an already installed system from libc 5 to glibc 2 is not completely straightforward. See the Glibc2 HOWTO for more information. Much easier is (re-)installing a -Linux distribution based on glibc 2, such as RedHat 5.1.

+Linux distribution based on glibc 2, such as RedHat 6.

C.4: Where can I find glibc 2 and the version of LinuxThreads that goes with it?

@@ -237,6 +237,31 @@ For libc 5, see ftp:/ For the libc 5 version of LinuxThreads, see ftp://ftp.inria.fr/INRIA/Projects/cristal/Xavier.Leroy/linuxthreads/.

+

C.6: How can I recompile the glibc 2 version of the +LinuxThreads sources?

+ +You must transfer the whole glibc sources, then drop the LinuxThreads +sources in the linuxthreads/ 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. +

+ +

C.7: What is the correspondence between LinuxThreads +version numbers, libc version numbers, and RedHat version +numbers?

+ +Here is a summary. (Information on Linux distributions other than +RedHat are welcome.)

+ + + + + + + +
LinuxThreads C library RedHat
0.7, 0.71 (for libc 5) libc 5.x RH 4.2
0.7, 0.71 (for glibc 2) glibc 2.0.x RH 5.x
0.8 glibc 2.1.1 RH 6.0
0.8 glibc 2.1.2 not yet released
+

+

@@ -271,11 +296,11 @@ descriptor opened on a pipe. When I link it with LinuxThreads, You're using one of the buggy versions of libc (5.3.12, 5.4.7., etc). See question C.1 above.

-

D.4: My program crashes the first time it calls -pthread_create() !

+

D.4: My program creates a lot of threads, and after +a while pthread_create() no longer returns!

-You wouldn't be using glibc 2.0, by any chance? That's a known bug -with glibc 2.0. Please upgrade to 2.0.1 or later.

+This is known bug in the version of LinuxThreads that comes with glibc +2.1.1. An upgrade to 2.1.2 is recommended.

D.5: When I'm running a program that creates N threads, top or ps @@ -359,6 +384,55 @@ stack-allocate some data structure, and pthread_cleanup_pop to close that block. It's ugly, but it's the standard way of implementing cleanup handlers.

+

D.9: I tried to use real-time threads and my program +loops like crazy and freezes the whole machine!

+ +Versions of LinuxThreads prior to 0.8 are susceptible to ``livelocks'' +(one thread loops, consuming 100% of the CPU time) in conjunction with +real-time scheduling. Since real-time threads and processes have +higher priority than normal Linux processes, all other processes on +the machine, including the shell, the X server, etc, cannot run and +the machine appears frozen.

+ +The problem is fixed in LinuxThreads 0.8.

+ +

D.10: My application needs to create thousands of +threads, or maybe even more. Can I do this with +LinuxThreads?

+ +No. You're going to run into several hard limits: + +(Other POSIX threads libraries have similar limitations, by the way.) +For all those reasons, you'd better restructure your application so +that it doesn't need more than, say, 100 threads. For instance, +in the case of a multithreaded server, instead of creating a new +thread for each connection, maintain a fixed-size pool of worker +threads that pick incoming connection requests from a queue.

+

@@ -519,7 +593,7 @@ be passed a C function as third argument.

F.3: I'm trying to use LinuxThreads in conjunction with libg++, and I'm having all sorts of trouble.

-From what I understand, thread support in libg++ is completely broken, +>From what I understand, thread support in libg++ is completely broken, especially with respect to locking of iostreams. H.J.Lu wrote:
If you want to use thread, I can only suggest egcs and glibc. You @@ -540,7 +614,14 @@ version of gdb 4.17 developed by Eric Paire and colleages at The Open Group, Grenoble. The patches against gdb 4.17 are available at http://www.gr.opengroup.org/java/jdk/linux/debug.htm. Precompiled binaries of the patched gdb are available in RedHat's RPM -format at http://odin.appliedtheory.com/. +format at http://odin.appliedtheory.com/.

+ +Some Linux distributions provide an already-patched version of gdb; +others don't. For instance, the gdb in RedHat 5.2 is thread-aware, +but apparently not the one in RedHat 6.0. Just ask (politely) the +makers of your Linux distributions to please make sure that they apply +the correct patches to gdb.

G.2: Does it work with post-mortem debugging?

@@ -668,11 +749,11 @@ signals available and the kernel reserves all of them but two: SIGUSR1 and SIGUSR2. So, LinuxThreads has no choice but use those two signals.

-On recent kernels (late 2.1 kernels and the forthcoming 2.2 kernels), -more than 32 signals are provided in the form of realtime signals. -When run on one of those kernels, LinuxThreads uses two reserved -realtime signals for its internal operation, thus leaving -SIGUSR1 and SIGUSR2 free for user code.

+On recent kernels (2.2 and up), more than 32 signals are provided in +the form of realtime signals. When run on one of those kernels, +LinuxThreads uses two reserved realtime signals for its internal +operation, thus leaving SIGUSR1 and SIGUSR2 +free for user code. (This works only with glibc, not with libc 5.)

H.5: Is the stack of one thread visible from the other threads? Can I pass a pointer into my stack to other threads? @@ -717,7 +798,7 @@ Windows client?

The best solution is to use X libraries that have been compiled with multithreading options set. Linux distributions that come with glibc 2 as the main C library generally provide thread-safe X libraries. -At least, that seems to be the case for RedHat 5.

+At least, that seems to be the case for RedHat 5 and later.

You can try to recompile yourself the X libraries with multithreading options set. They contain optional support for multithreading; it's @@ -741,7 +822,7 @@ only.

thread-safe X libraries that you could distribute? No, I don't. Sorry. But consider installing a Linux distribution -that comes with thread-safe X libraries, such as RedHat 5.

+that comes with thread-safe X libraries, such as RedHat 6.

I.3: Can I use library FOO in a multithreaded program?

-- cgit 1.4.1