Messages in this thread | | | From | Albert Cahalan <> | Subject | Re: proc fs and shared pids | Date | Tue, 6 Aug 1996 20:09:49 -0400 (EDT) |
| |
eiserloh@llab.chinalake.navy.mil (Peter P. Eiserloh) writes:
> All threads within a process have the same pid (no ifs and or buts). > Threads are identified with their own identifier (tid).
A user should see this as pid.tid for running shell commands.
> 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.
They need to register independant handlers. Think of SEGV and FPE in a process with many threads. They _also_ need global handlers, but that could be hacked in userspace by just forwarding signals as a message from one thread to another.
> You cannot identify a single thread by a pid, you need a tid!
The pid is 16 bits. A 16-bit tid can fit in the top bits to create a 32-bit global thread identifier. Users can use pid.tid to identify a particular thread, or just the pid to mean everything. Number the threads from one and let zero mean "all threads" so that the old software works. Then you can "kill -9 1234" for the whole process or "kill -9 1234.12" for just thread 12.
> 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.
kill -9 1234 # normal, all threads or the single thread kill -9 1234.0 # means the same as above kill -9 1234.12 # new, just thread 12 please
> 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.
I would assume that threads cooperate (can tell each other who has a handler for what) and that the outside world will not care.
>> 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.
Over 32000 threads on a 32-bit machine?
| |