lkml.org 
[lkml]   [1999]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: linux-kernel-digest V1 #4149
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [from the cache]
©2003-2011 Jasper Spaans