Messages in this thread |  | | Date | Thu, 24 Aug 2000 06:02:26 -0600 | From | yodaiken@fsmlabs ... | Subject | Re: SCO: "thread creation is about a thousand times faster than on native Linux" |
| |
On Wed, Aug 23, 2000 at 09:54:55PM -0700, Linus Torvalds wrote: > > > 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,
How about allowing the thread root process to do all that junk by giving it raw signals - e.g. delivering SUSPEND - and then letting it distribute via a pthread_kill?
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
- 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/
|  |