Messages in this thread | | | Date | Fri, 16 Jul 1999 14:18:27 +1000 | From | Richard Gooch <> | Subject | Re: 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/
| |