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/