Messages in this thread | | | From | cd_smith@ou ... | Date | Mon, 2 Aug 1999 09:58:38 -0500 (CDT) | Subject | Re: linuxthreads and tid testing |
| |
On Mon, 2 Aug 1999, Eric Paire wrote: > I don't think that Linus Torvalds is ready to see the notion of thread id > to invade the kernel
I think you've got a point. Put that's not going to stop me from coming up with the best implementation I can, proposing it, and then at least having the discussion.
> for what we want to do in user space. I just think that we should be able > to hide from a user space program the fact that the POSIX semantics wants > to attribute 1 PID to all threads to a program.
I agree you could probably kludge something up with libc wrappers. I don't agree that it would be better than a very simple and elegant solution in kernel space. Which is what I'm trying to do. And will post eventually, but I haven't done any kernel hacking and I'm having to learn the kernel as I go, which makes this a bit harder.
> BTW, If the fact that getpid() is a CLONE_PID rule exception hurts you, > then a simple way to avoid such is to return 2 pids (as for fork): > 1) the standard one (which is the one potentially fixed by CLONE_PID), and > 2) the effective one (as seen by the kernel).
Which unfortunately changes the semantics of the fork system call. I'd rather always return the PID without CLONE_PID, or the TID when CLONE_PID is used (since the PID is implicit in that case). But I haven't quite decided yet, because that's a little ugly in its own right.
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/
| |