To:	linux-kernel@vger.rutgers.edu
From:	torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Slow pthread_create() under high load
Date:	28 Mar 2000 10:52:49 -0800

In article <20000328014126.A2740@xman.org>,
Christopher Smith  <x@xman.org> wrote:
>
>IMHO, at least sharing PIDs would be a useful thing. Signal queues
>would be nice, but there are other ways to deal with that.

I don't understand the pid sharing argument. Just cache the pid of the
parent process, you're done. 

Many UNIX implementations do something like this in their getpid()
routine anyway:

	static pid_t mypid = 0;

	pid_t getpid(void)
	{
		if (!mypid)
			mypid = __getpid();
		return mypid;
	}

They do it because system calls on most UNIXes are quite slow, and
"getpid()" is used by some (bad) benchmarks to test for system call
speed. Doing it for those reasons is bad.

But the "optimization" in itself is not bad, it's just the _reason_ for
it historically that I dislike. If you take the above code, and add the
code to initialize "mypid" on pthread_create(), then suddenly you have a
(a) faster getpid() (not that it should matter) and (b) it gives you
POSIX behaviour for the subthreads. What's the problem?

Note that the reason the kernel is not POSIX-compliant is:
 - the POSIX standard is technically stupid. It's much better to use a
   cleaner fundamental threading model and build on top of that.
 - things like the above are just so much better and more easily done in
   user space anyway.

The reason LinuxThreads has a hard time becoming POSIX-compliant is that
I refuse to apply stupid patches, and a lot of the patches sent to me
have been frankly stupid. They've often implemented pthreads
functionality without any actual thought of how it _could_ be done more
cleanly with a user/kernel split. Again, see above.

Anyway, check out the netscape/mozilla threading library, and the one
from Apache (which I think is based on the mozilla one). They may just
fit your needs..

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/