On Thu, 15 Jul 1999, Larry McVoy wrote:
> : Actually, you can kill any one that is not blocking the signal at the
> : point that you send it (or one that has it masked but is blocked in
> : sigwait waiting to handle the signal). How do I do that under Linux right
> : now?
>
> No, you can _all_ that are not blocking the signal. How do I use kill(2) or
> kill(1) to kill a specific one of them?
Just for clarity, the way POSIX threads are specified right now says that
a signal sent to a process will be delivered to any one thread in that
processes that:
a) is not blocking the signal via pthread_sigmask(), OR
b) is waiting on that signal with sigwait()
If no thread meets any of the above circumstances, then the signal will
remain pending at the process level until any thread does meet one of the
above, at which time it will be delivered. Which thread receives the
signal is not specified, but it will only be one thread. The signal is
NOT delivered to all threads at once.
This is useful for a very large class of applications, and perfectly
intelligent people solving real-world design problems very frequently run
into a wall when they find out that LinuxThreads doesn't comply with the
standard in this respect. The reason: it is impossible to implement this
currently, using Linux's clone().
> This is completely orthogonal to the threads/process discussion. The same
> problem exists (and has been solved multiple ways) for processes.
Actually, the specific problem has NOT been solved for processes. It's
been solved by not using signals and using select() instead, but that's
only useful when select() applies (ie, using file descriptors).
Yes, it would be possible to solve the problem for processes and threads
simultaneously by playing some word games. Basically, what's now called
threads would be called processes, and I'd have to invent something called
"clusters of process" or some other strange name to which signals would be
sent, which would then handle delivering the signal to a process. This
wouldn't change what can be done, but it would confuse a lot of people
based on your insistence that "process" be some basic entity.
Since I'd wager that 99% of operating systems today use "process" to refer
to a collection of threads... and indeed even most of the linux kernel
calls scheduling entities tasks instead of processes, I see no reason to
insist on the word process in this case.
> The right answer is to solve it for the general case; then it works for
> threads and it works for problems that don't need the thread model (HTTP
> servers, for example).
[...]
> I think CLONE_PID is a crock of doo doo and should be shot dead. It's the
> wrong answer. They aren't one process, they are N processes. Pretending
> that they are one process is just the wrong answer.
No, the right answer is to not get stuck in the past. Except to someone
that has been around UNIX before threads were there, the fact that there
are five instances of apache running on the same system looks mighty
strange. All five "processes" are doing the same thing, and it is only a
relic of the past that we show apache five times. In other words, USING
PROCESSES FOR CONCURRENCY IS A KLUDGE. It is a left-over from times when
an alternative wasn't available, when people were just looking for some
way -- any way -- to shoehorn concurrency into a system interface that
was designed before anyone had even considered that one process might
want to use it. It's used today because thread interfaces aren't portable
(Linux is part of that problem), and because people are used to doing
things that way.
If I'm running apache, all I want to know is that I have a web browser
running. Since neither I nor my other processes on the system understand
exactly how apache is dividing its workload between five forked copies,
neither I nor my other processes need to see apache as anything but a
single entity, the web browser. Doing otherwise is akin to letting one
process muck around in another's unrelated process's address space. It's
a clearly bad idea.
A note about the above: there's one other possible advantage to processes
under most UNIXes right now: some additional reliability from MMU
protection. Part of the beauty of Linux's clone interface is that it
makes that available even without having several processes. I can say
clone(everything but CLONE_VM) and do the same thing without the confusing
mess of calling myself multiple processes.
> : Not from outside the process, anyway. A process is a single entity to
> : outsiders... under normal operation (not debugging), one process playing
> : with the internal details of how another process is implemented seems
> : pretty dumb to me.
>
> Using that logic, we should just remove the kill(2) interface. I doubt
> that, upon reflection, you really want to do that.
Huh? Come again? What logic have you used to deduce that somewhat
outrageous claim from what I said? I think we should keep kill(2), and
trash the old, losing attitude that constrains what we think a process can
do and requires some odd kludges to work around that.
Chris Smith <cd_smith@ou.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/