> At the recent open source database summit, I asked the developers
> there whether people had problems with threads on Linux.
> The answer I got was that the semantic differences from POSIX weren't
> really a problem, but they really, really wanted better debugging.
Actually, certain applications potentially beneficial to Linux (such
as Java) have a lot of problems with the non-pthreads semantics of
current Linux threads (both GNU pthreads and glibc API sets).
Here is a (probably incomplete) list:
1) It doesn't handle signals correctly. [We knew this]
2) core dumps of multi-threaded codes don't contain all the threads
(or even the crashing one !) [does the new gdb fix this?]
3) getpid() doesn't return the same value for all threads in a single process.
4) A child process fork()ed in one thread often cannot be wait()ed for
a different thread, depending upon the exact parent-child relationships
5) Threads *have* parent-child relationships (when they should properly all
6) uid/gid information isn't common to all threads in a single process,
so (for example) a multithreaded setuid/setgid process can have a
*very* interesting time.
7) rlimit information isn't common to all threads in a single process.
8) A multithreaded session leader process cannot do things like
disconnecting from a controlling tty in any thread other than its first.
9) "times" doesn't account for other than the thread it is called in.
10) libraries may not be (probably aren't) pthread_cancel safe. This is a
Fundamentally these problems all arise from the fact that as far as the
kernel is concerned a thread really is just a process which happens to
share an address-space and file descriptors with some other processes.
But we knew this....
Mark S. Brown email@example.com
Senior Technical Staff Member 512.838.3926 T/L678.3926
IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM
IBM Corporation, Austin, Texas