lkml.org 
[lkml]   [1999]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kernel thread support - LWP's
cd smith writes:
> Jamie Lokier wrote:
> > Larry's given a very nice set of reasons why different ids for
> > different threads is useful.
>
> Larry McVoy wrote:
> > [quite a bit]
>
> and Richard Gooch wrote:
> > Sure, I'm happy with a new kind of process group. In the docs we can
> > say "this is for threads". Couple that with a new kill() syscall which
> > does "kill one of a group" and we can support POSIX semantics.
>
> Okay, I'm beginning to notice a trend here... would people be
> happier if I gave you a patch that did this "process clustering"
> thing I keep mentioning? I despise the idea, and I still think it's
> a lot cleaner to do it the normal way... but it wouldn't be any
> trouble to do both. If I understand Larry correctly, though, I
> don't think that would placate his objections. :(

I'd say the first thing to do is add a way of killing just one task in
a process group. Probably that requires a new syscall. Alternatively,
we can make it a flag bit to the signal number. Making it a flag bit
has advantages (see below).

This is something that would be generally useful, and doesn't preclude
other changes. We would then be at the point of being able to support
POSIX semantics, with the proviso of breaking expected process group
semantics.

Then, if we decide that we really shouldn't "steal" process groups for
POSIX thread semantics, we can define a new process group, and
document that as being for threads.

After that, we could define another signal number bit (this is why
defining bits is better than adding a new syscall) which means "send
to the other process group for threads".

Of course, we still won't have true POSIX thread killing semantics,
because kill (pid) will deliver to the leader of a set of threads,
rather than a thread which can accept the signal, but it will be a
closer approximation.

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. I can see why he hates it: it's just a completely arbitrary
distinction. Unix already had a mechanism for grouping processes. It's
not clear why it was necessary to invent a new mechanism for grouping
them.

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. In the end, though, I think it's just more trouble than
it's worth. Not just from the kernel implementation point of view, but
also from user space. I once wanted to selectively stop some threads
in nfsd on Solaris, and I couldn't do that easily. I had to root
around in /proc to target the individual threads. Yuk. What I wanted
to do was:
# kill -STOP pid

and stop the particular thread I was after.

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.

> Richard again:
> > I think we've gotten to the point where we're better off violating
> > (obscure) POSIX semantics and keeping the kernel clean, rather than
> > uglifying the kernel to support unnecessary semantics.
> >
> > Others may disagree ;-)
>
> That would be me (disagreeing, that is). IMVHO we'd be better off
> just screwing POSIX altogether than pretending to support it, only
> to disagree on points like this. We either support POSIX, or not,
> and "almost" supporting standards has already caused enough grief by
> commercial companies who have an incentive to tell lies like that.
> We don't have to do so as well.

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.

Still, my preferred option is that POSIX drops the distinction between
processes and threads. We should lobby for that.

Regards,

Richard....

-
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    [W:0.082 / U:4.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site