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

From: Linus Torvalds (
Date: Wed Aug 23 2000 - 23:54:55 EST

On Thu, 24 Aug 2000, Albert D. Cahalan wrote:
> Nobody will send you a sane patch without you at least hinting
> at what you might like to see. I'm sure many of us would be happy
> to write the code, but not under the expectation that it will
> be rejected.

Acceptable solution:
 - add "tgid" (thread group ID) to "struct task_struct"
 - CLONE_PID will leave tgid unchanged.
 - non-CLONE_PID will set "tgid" to the same as pid
 - get_pid() checks that the new pid is not the tgid of any process.

Basically, the above creates a new "session pid" for the collection of
threads. This is nothing new: the above is basially _exactly_ the same as
p->pgrp and p->session, so it fits quite well into the whole pid notion.

It also means that "current->pid" basically becomes a traditional "thread
ID", while "current->tgid" effectively becomes what pthreads calls a
"pid". Except Linux does it the right way around, ie the same way we've
done sessions and process groups. Because, after all, this _is_ just a
process group extension.

Now, once you have a "tgid" for each process, you can add system calls to
 - sys_gettgid(): get the thread ID
 - sys_tgkill(): do a pthreads-like "send signal to thread group" (or
   extend on the current sys_kill())

Now, the problem is that the thread group kill thing for true POSIX
threads signal behaviour probably has to do some strange magic to get the
pthreads signal semantics right. I don't even know the exact details here,
so somebody who _really_ knows pthreads needs to look long and hard at
this (efficiency here may require that we have a circular list of each
"thread ID group" - ie that we add the proper process pointer list that
gets updated at fork() and exit() so that we can easily walk every process
in the process group list).

Discussion welcome. Basically, it needs somebody who knows pthreads well,
but actually has good taste despite that fact. Such people seem to be in
short supply ;)


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:12 EST