Messages in this thread | | | From | cd_smith@ou ... | Date | Thu, 15 Jul 1999 21:15:42 -0500 (CDT) | Subject | Re: 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/
| |