Re: Threads
> At the recent open source database summit[1], 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
by
a different thread, depending upon the exact parent-child relationships
between threads.
5) Threads *have* parent-child relationships (when they should properly all
be peers).
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
*bad* one.
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 bmark@us.ibm.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
Reply to: