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

From: Mark Kettenis (
Date: Thu Aug 24 2000 - 14:46:17 EST

   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 <>

      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

   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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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