Messages in this thread |  | | Date | Thu, 24 Aug 2000 21:46:17 +0200 | From | Mark Kettenis <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on native Linux" |
| |
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/
|  |