lkml.org 
[lkml]   [2001]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Provide system call to get task id
Date
In article <Pine.LNX.4.33.0110081110130.8212-100000@penguin.transmeta.com>,
Linus Torvalds <torvalds@transmeta.com> wrote:
>Now, I actually seriously doubt either of those are real issues, and it
>probably doesn't matter what we do. But I'd ratehr have a system call
>called "getpid()" do what POSIX threads have traditionally done, namely
>give the ID of the process group ("tpid" in linux kernel-speak), and have
>"gettid()" give the thread ID ("pid" in linux kernel-speak).

The kernel doesn't have pthread support - glibc emulates it using clone().
Shouldn't glibc then not also be the one to do the getpid() / gettid()
switching internally only for applications linked agains libpthread ?

If you want to have thread IDs I think you should go all the way
and make thread groups a real entity like sessions and process groups.
Setsid() would reset the thread group ID like it now also resets
the process group ID. Ditto for setpgrp() I think. A session can
contain several process groups which can contain several thread groups.

There should be a way to signal all processes in a thread group-
perhaps that should even be the default, a signal to any process
in the group should be delivered to all of them. Or perhaps only
for SIGSTOP and SIGKILL, all other signals could be delivered
to the thread group leader.

Anyway, food for thought.

Mike.
--
Move sig.

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

\
 
 \ /
  Last update: 2005-03-22 13:05    [W:0.044 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site