Re: SCO: "thread creation is about a thousand times faster than on native Linux"

From: Theodore Y. Ts'o (tytso@MIT.EDU)
Date: Thu Aug 24 2000 - 14:16:30 EST


   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/



This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:14 EST