There isn't. We discussed this some time ago (I don't remember with whom),
and it was felt to be generally a "good thing". It has the advantage of
allowing normal UNIX utilities to automatically work both on the whole
"process" (in the traditional thread meaning) while still allowing the same
utilities to handle individual threads if they wanted to.
Traditional threads suck. The whole idea with the Linux "clone()" was to look
at the thread idea from a new perspective, and have something that makes the
difference between threads and processes fade away. We want to have threaded
programs, but we ALSO want to not think of the threads as anything special:
they are just another form of processes. As such I don't want special thread
system calls, instead I want _generic_ system calls that work both in a
thread and a process context. That's why I proposed the high-bits thread-ID
approach.
The only problem as far as I'm concerned is that I don't actually use the
thread facilities, and as such I'm unlikely to start coding. I've been hoping
that people that are interested in threads start using clone() for them
(which finally has happened, thank God), and that as it becomes clear that we
need more support (like the thread ID thing) people start sending me patches.
Hint hint..
Again, I'd like people not to look too closely at pthreads or other
"traditional" threads packages. If people _do_ start playing around with the
kernel for better thread support, please don't try to force any pthread
specific system calls or anything like that. Think in more generic terms, and
do any new system calls (if needed) in such a way that you can implement
pthreads on top of them, but don't limit yourself to any specific interface.
Try to make the system calls make sense even _outside_ a threaded
environment.
Linus