We need to keep a clear the concept of threads. Too many people
seem to confuse a thread with a process. The following discussion
does not reflect the current state of linux, but rather is an
attempt to stay at a high level discussion.
All threads within a process have the same pid (no ifs and or buts).
Threads are identified with their own identifier (tid).
A thread is not a process, a thread runs within a process.
When the last thread exits, then the process is removed.
Many threads can run within a process, some even simultaneously,
on multiple processors. The process is only an environment within
which its set of threads can run. The process consists of
its pid, VM, files, environment variables, signal handlers (along
with which tid they belong), and its set of threads.
NOTE: the process does not contain the execution context.
All execution happens within a thread, under the umbrella of the
process. A thread consists of its pid, and tid, priority,
execution context, current (or previous) processor, and signal handlers.
The scheduler schedules threads not processes.
All of these threads share the same pid. When you
"kill -SIGWHATEVER pid"
you send the signal to the process, which may have handlers
registered by any of its threads. If a handler is not registered
when a signal is received then all that process's threads are
terminated, along with the process. If a signal handler is already
registered when a different thread attempts to register it, then
the old one is replaced by the new one. Alternatively we could
decide this is an error condition.
You cannot identify a single thread by a pid, you need a tid!
A thread can only run on one processor within one quantum.
The thread's current/prior processor will be given preference
when scheduling a given thread (due to caching). A thread
may require a particular processor, in which case only that
particular processor can schedule it.
A process may be running upon many processors via multiple threads.
Which processor is normally not important, and if the process
has only one process, it may wander around from processor to
processor.
Not all processors need to be running the same process. Many
threads from different processes may be executing simultaneously.
If you need to kill a specific thread within the process we will
need additional syntax
c:
tkill(tid, SIGWHATEVER);
or tkill(pid, tid, SIGWHATEVER);
command line:
kill -SIGWHATEVER -t tid
or kill -SIGWHATEVER pid -t tid
The first syntax is used if the tids are assigned from a common
pool, whereas the second one would be needed if the tids are not
unique (assigned within the process, where each process has a
tid 0). I suggest we use a common pool so we don't have to
identify both the pid, and tid.
A thread registers a signal handler with it's process using
the current syntax.
We may want to have a new system call which can identify the
thread which owns a signal handler.
>Is a 16-bit pid enough? I could imagine wanting some extra bits
>to specify what processor node so that it would be easy to find
>the process in a Linux supercomputer. (if process migrates, drop
>the bits and search all nodes) I could also imagine running out
>of pids - BTW, does the kernel check for that or just get stuck?
>There are only around 30000 pids, and some systems have that many
>processors already.
Until you actually need 32000 simultaeous processes then 16 bits
should be enough. The real question is whether or not 16 bits is
enough for the tid. For the massively parallel machines such as
the connection machine and its successors 16 bits will NOT be enough!
Each process may have thousands of threads.
Peter
-----