Messages in this thread |  | | Date | Mon, 8 Oct 2001 11:17:09 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [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/
|  |