Date: Thu, 24 Aug 2000 15:16:30 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Date: Thu, 24 Aug 2000 14:36:12 +0200 (MET DST)
From: Mark Kettenis <kettenis@wins.uva.nl>
Linus is right. There just seems to be nobody with the right set of
skills who is interested in doing the work, so it just doesn't get
done.
I'll echo this. In the Linux Standards Base group, it was hard to find
*anyone* who was actually psyched about Posix Threads. Even most of the
database vendors we talked didn't care --- they had their own
multithreading solutions that was either fine with the existing
Linuxthreads, or emulated it using processes and shared memory.
According to one db vendor we talked to, there are enough
incompatibilities in other OS's thread implementations that they don't
like to depend on POSIX threads at all.
There is certainly a large demand for POSIX threads by Linux
programmers. It's just that many of to so-called "problems" with the
current implementation (bad performance, especially in the case of
pthread_create(), signal handling) are in 99% related to bad
application design. Programmers that have a clue recognize these
things and fix their programs. Clueless users obviously aren't the
ones that are going to fix the kernel.
On the issue of 1:1 versus 1:many:
I realize now that I really meant to compare 1:1 with n:m, not 1:many.
* The consesus on comp.programming.threads seems to be that 1:1 is
preferable over 1:many. It seems to be too difficult to get the
1:many right, and the Solaris' two-level library seems to have
considerable problems. That's why there is an additional 1:1
library in Solaris 8.
Heh. Part of the reason why Posix threads has such broken semantics is
because the standards committee wanted to make 1:many implementations
possible. That's why the signal semantics are so.... interesting.
I believe I read on comp.programming.threads that the interaction with
job control was another reason for the "interesting" semantics. Those
semantics are causing me a major headache with implementing POSIX
threads for the Hurd :-(.
My understanding is that there are some broken applications out there
(which unfortunately include Java) which require a n:m threads
implementations, because they think it's amusing to create (in some
caes) hundreds of thousands of threads, and a 1:1: model simply falls
over in the face of such a (unreasonable?) number of threds.
Running out of address space (for thread stacks) seems to be the
biggest problem in such cases with the LinuxThreads threads
implementation.
Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:14 EST