lkml.org 
[lkml]   [2001]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Provide system call to get task id

On Mon, 8 Oct 2001, Alan Cox wrote:
>
> Would it make more sense to add a getpid() and make the existing one
> gettid() to keep compatibility at its sanest ?

I don't think compatibility is an issue: programs that are (a) threaded
and (b) use the new thread group interface and (c) care about tid simply
do not exist. For the simple reason that they cannot exist - getpid() was
changed at the same time CLONE_THREAD was added.

So the only compatibility worry would be

- people using non-thread-aware libraries together with a CLONE_THREAD
core thing - which is possible especially if they have thread wrappers.
But if those libraries care about "pid/tid" issues, there's no way that
can have well-defined behaviour anyway ;)

- people who have been playing with CLONE_THREAD, and have apps that
depend on the "pid is the 'classical' pid, not the thread ID"
behaviour. In which case adding a new gettid() is the right thing to
do.

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

Linus

-
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:04    [W:0.128 / U:1.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site