> 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?