lkml.org 
[lkml]   [1999]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: linux-kernel-digest V1 #4149
Date
From
: 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.

You're right. Point conceeded, but it then raises another point. This is
a different, you can argue whether it is useful or not, semantic for
signals, along with a different set of interfaces for manipulating them.
Why? I can construct the same behavior in LinuxThreads using interfaces
that have been here for 20 years or more. The only thing that is not
true about that statementis that I have to be deterministic about which
thread gets the signal, and the POSIX standard lets the system pick one
at random. Personally, I'd prefer to be deterministic. It makes debugging
a hell of a lot easier.

: This is useful for a very large class of applications...

Why? What's better about it?

: > 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.

All of this misses my point completely, or at least it sure sounds like it
does.

My point is that there should be exactly one kind of process primitive.
I could care less if you call it a thread, a process, a task, or
a foobar. There shouldn't be two or three or four different ones any
more than there should be two or three or four file system interfaces.
N different instances of the process/thread/whatever class just like
there are N different instances of the file class (i.e., ext2, iso, NFS,
etc), is fine. My complaint about threads for the last 11 years (ever
since I implemented a user level threads package in 1988) has been that
threads are just a variation on the process theme - there is nothing
unique about threads as compared to processes.

Imagine what you, Chris, would say if I came along with a new file system
type and I wanted to create a whole new object class in the system to
support this file system type. I suppose you might support it if it
had significant value _and_ it was impossible to implement within the
constraints of the current file system class. But what if you could
implement it within the existing file system class? But I wanted to do
a new class, for whatever reason. What would you say? I kind of think
you'd think that I was crazy or that I didn't understand that file system
class.

I'm not saying you or the POSIX guys are crazy, but I am trying to say that
you can quite happily implement all the semantics you want within the process
class - you don't need a different class. You may want to add a method or
two to the process class, but in all the cases - like signal handling, for
example - where the two classes are doing basically the same thing, it's
just plain bad design to add a new way to do the same thing. Reuse the
old way. By all means, add what you need in terms of new interfaces,
but do not reinvent the old ones with new names.

: 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.

Can't agree. I really like that I can do a ps axu | grep http and
see
nobody 23937 0.0 3.5 3152 2268 ? S 08:24 0:00 httpd
nobody 23939 0.0 3.5 3152 2264 ? S 08:24 0:00 httpd
nobody 25502 0.0 3.5 3152 2260 ? S 12:11 0:00 httpd
nobody 25946 0.0 3.5 3152 2260 ? S 13:14 0:00 httpd
nobody 25950 0.0 3.5 3140 2260 ? S 13:14 0:00 httpd
nobody 26079 0.0 3.5 3140 2256 ? S 13:36 0:00 httpd
nobody 26089 0.0 3.5 3152 2260 ? S 13:38 0:00 httpd
nobody 26093 0.0 3.5 3140 2256 ? S 13:38 0:00 httpd
nobody 26094 0.0 3.6 3212 2324 ? S 13:38 0:00 httpd

That tells me something. In this case, it sort of suggests that I don't
need more than 6 of 'em, 2 of them aren't getting used very much.

In general, each time some bright mind comes up with some new idea,
I want that idea to be wedged into some existing interface - be it a
device, a file, a process, a socket, whatever. The object orientedness
of operating systems has supported this and shown it to be a great model
for 40 years. In fact, the idea of a device as an object with a fairly
fixed set of interfaces is often held up as one of the great contributions
of operating systems - it certainly is the first example of an "object"
and predates C++ by about 20 years.

If we didn't "get stuck in the past" we would have different entry points
for tapes, keyboards, mice, disks, etc., instead of the good old
open/close/read/write basics.

: 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.

Hmm. So is letting one thread muck about in another thread's address space
a bad idea also? Clearly not. So you want to decide for me whether or not
I can view threads individually or not. With all due respect, no thanks.
If you want to not see 8 http processes, I'll happily write you a version of
ps which finds all of them, adds up their resource usage, and reports them
as one entity. I can do that and satisfy your needs. However, you can
not satisy mine with your model - if I want to see what each thread is doing,
I can't use top/ps/strace/ltrace or any of the other process oriented tools.
ALL of those have to be rewritten. And without OS support, some of them
can not be rewritten. Once again showing you that the process model can
emulate the threaded model but not the other way around.

: > : 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.

kill(2) is used all the time to modify the internal workings of some
other process. You have to know that kill -HUP 1 will cause init to
reread it's config file. That is a useful thing that your statements
sure sound like you want to have go away.

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

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