Re: kernel thread support - LWP's

Richard Gooch (rgooch@atnf.csiro.au)
Fri, 16 Jul 1999 11:16:39 +1000

Jamie Lokier writes:
> Richard Gooch wrote:
> > Yes, you could use process groups to emulate POSIX thread killing
> > semantics, but that requires your "heavyweight process" to switch to a
> > new process group. That might not always be what you want (and may
> > possibly violate POSIX). So I'd be happier if we could find some clean
> > and lightweight way of adding a new grouping mechanism so we can
> > properly support POSIX thread killing semantics *and* not interfere
> > with process groups.
>
> If I type ^C after "this | that | other" I expect it to kill all the
> threads in all the processes... not just all the threads in one of the
> processes.
>
> Looks like an argument for another kind of process group, rather than
> eliminating process ids for individual threads.

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.

> Larry's given a very nice set of reasons why different ids for
> different threads is useful.

I don't disagree with those points. I must say I really like the way
clone() works. It Looks Right.

The question in my mind is whether there is a way of providing POSIX
semantics cleanly, or do we tell POSIX to shove it? If at the end of
the day, we can't cleanly provide POSIX semantics, we should try and
get POSIX fixed^Wchanged. If that's not possible, I say we tell them
to get rooted. 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 ;-)

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/