Messages in this thread |  | | | Subject | Re: linux-kernel-digest V1 #4149 | | Date | Thu, 15 Jul 1999 20:52:33 -0600 | | From | Larry McVoy <> |
| |
First of all, Chris, let me say I appreciate the work you're doing, it's great that you are working on this stuff. Just because we don't see eye to eye doesn't mean I have to be rude about it so I'll ease off a bit.
Second of all, what I'm hoping is that I can get you to look at some of this in a different way. I'm more than a little worried that my style is just going to piss you off and make you ignore everything I'm saying. So I'll try and be less inflammatory...
: 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
I think we could aspire to better reasons than agreeing with POSIX. POSIX is great, but POSIX should specify something when it is common practice. Common practice can result in a standard, but the converse is rarely true and almost 100% of the time results in a flawed standard.
: 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?
We do. We group in process groups and deliver with kill(). The current semantics of process groups and signals aren't complete but they are really close. Let's just extend them a little to do what you need.
: > : 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'll agree with you that wakeup one semantics on select or on a signal are useful thing. But that can be handled in a general way that is orthogonal to threads vs processes. If you do it right then the same changes are useful for old designs (like the web servers) as well as for the threading models you want. This is the crux of my argument: try hard to get it right for the general case - threads are special case, they are not the general case.
: 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!
First of all, just use the existing process groups. While this can be somewhat annoying, it is perfectly capable of handling what you need for threads since they are all related (the only real problem with process groups is that unrelated processes can't join them - this is something I'd really like to see fixed, but's off topic here since pthread_creat() implies a common ancestory so the processes/threads are all related and a process group mechanism will work fine).
: 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.
I don't see three cases, I just see one: a process group and sending signals to a process group (well, two, because you need to send signals to processes, but let's ignore that).
I have yet to see an example where a process group doesn't do the right thing for what you want. I'll be happy to agree that signal deliver semantics need to be extended so that a signals sent to a process group have "signal one" semantics, but that doesn't mean you need another process group, it means you need another process method which modifies the signal semantics.
: we have to add a new system call to handle killing a process cluster.
No you don't, see above.
: we need some way to designate that a fork()ed process should be in a new : process cluster
fork() is just a variation on clone. It should obey standard process group semantics. Why do you think that fork should do something different?
: 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.
Let's not. I think we already have all the objects that you need to do what you want.
: 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.
The key point here is that I can get at the information if I know what it means without having to reinvent ps, top, kill, strace, ltrace, etc. In a thread based model where the threads are hidden behind a single process, someone has to rewrite all of those tools. I sure don't want to do that.
: > 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.
I think maybe you are giving up way too easily. Sure, it's harder to make things fit into an existing design. But it is almost always the right answer and people become quite good at it. Given your level of knowledge, I'm confident that you can do this _if_ you want to. This is where I'm most afraid that maybe my style is making you not hear what I'm saying. So try and ignore the fact that I'm about as tactful as a bomb and think hard about reusing what we already have.
: 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?
Well, I find the process/thread model to fundementally broken and the funny thing is that one of the primary architects of the model now seems to also agree that it is broken. At the time it was invented, nobody knew about clone(). If they had, then we would only have one kind of thread of execution, call it a process or call it a thread, who cares, there would only be one thing.
Anyway, I hope that we can work together towards something that is simple, makes sense for all sorts of threads (threads or processes), and is something that Linus would like. Let me know what I can do to help.
--lm
- 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/
|  |