[lkml]   [1996]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: CLONE_PID (was: POSIX.1b semaphores)

On Tue, 19 Nov 1996, Xavier Leroy wrote:
> 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.

My theory was that this case (high bits zero) would mean that the signal
is sent to _all_ the processes.

Now, the CLONE_PID stuff is not finalized, as you say, and in order to
make the "send-to-all" semantics efficient, we need to have a separate
pointer structure for "next process with same PID" (kind of like th thread
pointers that we now use for parent/child relationships). Because unless
we have something like that, we'd have to search through _all_ the
processes, even for the normal case when we aren't threading at all.

The other possibility I see is to always think of the "high bits zero"
process as the parent process to all threads (it is), and not special-case
the zero at all. If you send a signal with high bits zero, it goes to the
"parent", and nobody else.

I don't know what the exact POSIX requirements were for pthreads, and
that's probably what has to decide the issue. If POSIX allows the model
where only the "mother thread" gets the signals, use that. If POSIX
pthreads requires that _all_ threads get the signal some way, use the
"zero means all" algorithm and add the extra linked list of processes

Anyway, this is one area where the implementation is not something I feel
strongly about, and as such the deciding factor is what the standard says
and what makes it easiest for us. Feel free to send me patches..


PS. Oh, and while I'm orating here, I might as well tell everybody that
I've been busy writing my masters thesis, and as a result I've moved all
the mailing lists to a low-priority channel. I'll try to concentrate on my
thesis for a while, so I'll be less active than usual. Don't worry, this
is all temporary.

 \ /
  Last update: 2005-03-22 13:38    [W:0.119 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site