Well, it works but it's not usable in a thread library. What's missing
is the ability to send a signal to a particular "thread", i.e. one of
several processes having the same PID. LinuxThreads needs this feature
because it implements suspend thread/restart thread with signals.
Linus proposed a scheme whereas the high bits of the pid argument to
kill(2) would encode the "thread" number. That's all right, but still
needs to be implemented.
But wait, there's a second half to the problem. What happens if we do
kill(p, sig) when p is a regular PID (high bits 0) and there are
several processes with PID p ? Which one(s) get the signal?
The first process with PID p encountered while searching the process
table? No, because that process may block the signal while others with
the same PID don't. The first process with PID p that does not block
the signal? All right, sounds reasonable.
But what happens if all processes with PID p block the signal? Shall
we queue the signal on one of those processes chosen at random?
This does not sound very good, because if another thread unblocks the
signal later, it will not receive it since it's been queued on another
thread. If I understand the POSIX threads spec correctly, the signal
should be queued for the whole set of threads, and delivered to
whichever unblocks the signal later.
One approach would be to have an extra option to clone, say
CLONE_SIGPENDING, to share the set of pending signals between several
processes. That would be fairly close to the POSIX semantics, but then
we also need a per-thread set of pending signals for delivery of
signals to one thread in particular...
As you can see, this CLONE_PID flag, although working fine, opens a
whole can of worms in the area of signal delivery. If anyone has ideas
on how to approach this problem, please let me know.
- Xavier Leroy