Messages in this thread | | | From | cd_smith@ou ... | Date | Fri, 16 Jul 1999 02:38:05 -0500 (CDT) | Subject | Re: linux-kernel-digest V1 #4149 |
| |
On Thu, 15 Jul 1999, Larry McVoy wrote: > 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.
That's fine. I'm not really mad, even if I came across that way. I think I may be partially missing your point, but that's a different thing altogether...
> I think we could aspire to better reasons than agreeing with POSIX.
Certainly. I believe the snipped section there mentioned "unless there are compelling reasons not to". If there are compelling reasons not 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? > > 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.
I think Richard and Jamie both do a great job of explaining why process groups won't work here. So I'll just refer you to their posts.
> 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.
Okay, maybe. I'm still thinking about this. We'll talk tomorrow as planned.
> First of all, just use the existing process groups.
See above.
> 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).
Well, three cases if these new signal handling groups are different from process groups, which I'm pretty convinced they have to be. Only two if they're the same.
> I have yet to see an example where a process group doesn't do the right > thing for what you want.
Again, see Jamie's posts (and Richards, to an extent, as they also mention this).
> 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.
Well, we need some way to distinguish a process group as used in job control from a process group used to obtain these new signal semantics. I'm open to other suggestions for how to keep the two from interfering, but defining a new type of "group" seems cleaner than anything else I can think of.
> 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.
Like I've said before, sometimes tools break when they are based on old assumptions and you want to move forward. Each new release of Linux lists versions of various tools that are required to use that kernel version. I agree that we don't want to break tools if there's a better way, but real proper thread support needs new tools anyway.
> 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.
Broken how? I agree that it's broken as originally conceived. But I also see no conflict in providing process/thread with clone(). The only difference is that threads own resources, and the process owns ONLY a collection of threads. But you seem to disagree. You're creating a dichotomy between clone() and process/thread distinctions that I just don't see.
> At the time it was invented, nobody knew about clone(). If they had, > then we would only have one kind of thread of execution. [under > process/thread division model]
Err, we do have only one kind of thread of execution. A process is NOT a thread of execution. A process is simply a container for threads (and, in other implementations, resources like address space... but I think we ought to move those back to the thread level and share via clone() like we do now). That's it. Just a different type of group, exactly as I am fairly certain we'll need to invent anyway.
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/
| |