Thread deficiencies
Here are the at least some of the pthreads implementation problems.
- Ted
------- Start of forwarded message -------
To: Linux-Development-Sys@senator-bedfellow.mit.edu
Date: Thu, 25 Nov 1999 16:05:48 +0000
From: James Cownie <jcownie@etnus.com>
Subject: Thread limitations: Was Re: Getting CPU/system usage on a multithreaded application -- times() bug?
Sean Eddy wrote in summary:
"times" doesn't account for thread resource usage.
This seems like just one more thing to add to the list of known problems with
Linux' threads implemenation
1) It doesn't handle signals 100% correctly.
2) 'ps' shows every thread in a process.
3) core dumps of multi-threaded codes don't contain all
the threads (or even the crashing one !)
4) getpid() doesn't return the same value for all threads
in a single process,
5) 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.
6) Threads *have* parent-child relationships (when they
should properly all be peers).
7) 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.
8) rlimit information isn't common to all threads in a
single process.
9) A multithreaded session leader process cannot do
things like disconnecting from a controlling tty
in any thread other than its first.
10) "times" doesn't account for other than the thread it is
called in.
(Thanks to Jonathan de Boyne Pollard for most of this list).
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. Until the kernel knows to share more information
between threads these problems will persist.
- -- Jim
James Cownie <jcownie@etnus.com>
Etnus, Inc. +44 117 9071438
http://www.etnus.com
------- End of forwarded message -------
Reply to: