Messages in this thread |  | | Date | Mon, 05 Aug 1996 18:43:27 -0700 | From | "Peter P. Eiserloh" <> | Subject | Re: proc fs and shared pids |
| |
>Allowing threads to share pid's means we have to go through and rethink >what a lot of things mean. Do kill() and waitpid() operate on just >one thread or all of them?
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 -----
|  |