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

First and foremost, because POSIX specifies it, and in the absence of
compelling reasons to the contrary, I'd prefer that Linux be as compliant
to standards as possible. If you can point out how this works using
existing interfaces, please do. My understanding is that Xavier Leroy
tried and finally gave up, because without kernel support this can't be
done in any reasonable way. (I realize that being random isn't required,
and that being deterministic is good. I don't think anyone uses a random
number generator to choose a thread to deliver a signal to. :)

No, that doesn't mean kernel support is necessary in exactly the form I am
planning on implementing it, but it requires that the kernel provide some
abstraction that allows grouping tasks and delivering signals to them
under those semantics. Why not, for the sake of compatibility with other
UNIX implementations, call those groups processes?

> : This is useful for a very large class of applications...
>
> Why? What's better about it?

The fact that it allows an application that is using concurrency to
recognize and respond to an event, once, using some context that is most
expedient. You'd be surprised how many applications (none of which run on
Linux) are designed around a group of threads blocking in sigwait(). It
works, and it solves the problems people are trying to solve, so they do
it. Linux applications are very often designed around the same model with
select(), in the limited situations where that works. In short, a huge
amount of empirical evidence demonstrates that this model works.

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

I agree that we should reuse interfaces when they do essentially the same
thing. When the interfaces are essentially different, there's no reason
that we should try to shoehorn them into the same set of calls.

But okay, let's try to implement this signal thing using an existing
interface and using the classical UNIX definition of processes
(post-clone() semantics, that's essentially identical to what's typically
called threads today). Well, we need something resembling a process group
-- for lack of better terms, I'll call it a process cluster, to indicate
that it's closer bound than a process group. A signal sent to a process
cluster gets sent to some member that doesn't have it blocked. Great!

Oops, we could support process groups using negative pid parameters to
kill(2), but that doesn't work so well now that there are three cases. So
we have to add a new system call to handle killing a process cluster. And
we need some way to designate that a fork()ed process should be in a new
process cluster -- except that the common case now is that it isn't -- so
let's create a way to specifically state that the process cluster is
shared instead. Let's make it a parameter to clone (not unreasonable,
since clone's flags basically all designate something to be shared).

Sound good so far? Now let's take what we're calling a process and
rename it to a thread. Take what we're calling a process cluster and
rename it to a process. And call that clone() parameter CLONE_PID. Wow,
we've got essentially the same thing I already designed... we were just
giving things 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

a) This is all assuming you can make some assumptions about the
implementation of apache. In this case, work happens to be distributed
equally among a lot of processes. Not all thread applications are
symmetrical. You can use that information, of course, but only if you
happen to know how apache works.

b) If you really do want to assume that level of internal knowledge about
the process, you'll be able to get to exactly the same information with
threads around. It will just be formatted more conveniently for you.
Instead of being all at one level, you'll be able to see the web server,
and then in /proc subdirectories under that (eg, /proc/26037/1) will be
all that information about each thread that's a part of apache. Yes,
you'd need some changes to the tools, but if we can never break tools
based on old assumptions, then we've got problems.

> In general, each time some bright mind comes up with some new idea,
> I want that idea to be wedged into some existing interface

Unless the existing interface is insufficient. Like it is in this case.
And then the changes that need to be made are identical no matter which
new interface I invent. So I'm going to invent the one that makes the
most sense, and is most like the common usage.

Maybe it's just me, but the process/thread distinction seems so
fundamentally right that I'm not sure how anyone could disagree. That's
like telling me that multiprocessors are dumb because I could just buy two
uniprocessors and do one thing on each of them. Yes, I could, but why
would I want to?

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/

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