Re: linux-kernel-digest V1 #4149

cd_smith@ou.edu
Fri, 16 Jul 1999 02:38:05 -0500 (CDT)


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/