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/