Messages in this thread | | | From | cd_smith@ou ... | Date | Fri, 16 Jul 1999 02:49:18 -0500 (CDT) | Subject | Re: kernel thread support - LWP's |
| |
Hi,
On Fri, 16 Jul 1999, Richard Gooch wrote: > The bottom line is that we can't give exact POSIX semantics without > making that distinction between processes and threads that Larry hates > so much.
You're right. We do need the distinction, but I think the distinction we need is very fundamentally different from the one you and Larry are thinking about.
> I can see why he hates it: it's just a completely arbitrary > distinction.
No, it's not. You yourself just wrote a description about how to implement exactly this distinction -- only you called it "new process groups" and "processes". All that I'm saying is that Linux would fall in line with every other UNIX variant I am aware of if we named it "process" and "thread". (Actually, that last bit could be "task" to be compatible with a lot of kernel naming right now.)
I am very specifically NOT suggesting that we move information about address space and so forth into the process realm and out of the task realm. That would be dumb and would sacrifice flexibility, not gain it. All I want is a "process" that does pretty much what your "new process group" does.
> Unix already had a mechanism for grouping processes. It's > not clear why it was necessary to invent a new mechanism for grouping > them.
Hmm? It's because process groups and these new grouping needs conflict with each other, and we need a way to handle both cases in arbitrary combinations.
> I can see why POSIX did it that way: they wanted to make things easier > for non-thread aware programmes. So they tried to slip threads in by > the back door.
No, I don't think so. I think POSIX placed threads behind processes because that's where they belong. Because what threads are used in a process is the business of that process and no one else -- it can be made accessible in a low-level system interface like /proc for those cases where someone wants to screw around with it (debugging, etc); but it isn't exposed for the same reason that lost of process implementation isn't naturally exposed. It is a bad idea.
> There are times I want to treat threads as invisible parts of a > process (usually with ps). But there are other times I want to see > them all (usually with ps and kill). To satisfy both uses, and make > things simple, make the kernel expose all threads (like we do now), > and filter things out in ps.
Well, there's no question that the kernel will expose all threads. The question is how. I want it to expose threads as subdirectories of the process, and you want it to expose threads so that they look like processes. In either case, all of the information is available, and your tools will have to be rewritten either way to give you the choice you want.
> Don't get me wrong: I'm not saying we should lie about it. If we > decide to violate POSIX, we should be up front about it (and say > why). But we should still say we're mostly POSIX compliant. Probably > say "POSIX compliant except for ...". I don't think it has to be all > or nothing. If we violate an obscure part of POSIX, most people won't > care.
Well, this isn't a kernel thing anyway... we should definitely not expose the pthreads interface from the kernel. It should be built on top of the more expressive Linux interface. So I disagree, but it's off-topic anyway so I won't bother to argue.
> Still, my preferred option is that POSIX drops the distinction between > processes and threads. We should lobby for that.
And I'll lobby against you. Sorry. :)
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/
| |