Messages in this thread |  | | From | devnull@spaans ... | Date | Thu, 24 Aug 2000 15:16:30 -0400 | Subject | Re: SCO: "thread creation is about a thousand times faster than on native Linux" |
| |
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.
On the issue of 1:1 versus 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.
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.
- Ted - 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/
|  |