Messages in this thread | | | Subject | Re: linuxthreads and tid testing | Date | Mon, 02 Aug 1999 08:28:10 +0200 | From | Eric Paire <> |
| |
> On Fri, 30 Jul 1999, Eric Paire wrote: > > Don't you think that this should be the purpose of the CLONE_PID flag ? > > With this flag, all system calls returning the current pid would return > > the pid of the last clone() call without this flag set, except getpid() > > (in order to get a standard way to get the actual kernel pid of a > > CLONE_PID thread, and because this could be hidden by the libpthread). > > Doesn't this strike you as a bit ugly? If EVERYTHING is using the same > pid, then why not make getpid() use it as well, and then add a system call > to get the thread ID. It's NOT an appreciable amount of extra kernel > code, and it makes everything a lot more consistent. Keeping the kernel > small is an admirable goal, but not if it means inventing completely > pointless and arbitrary behavior to eliminate a few lines of kernel code. > Sometimes the kernel is the right place for implementing certain behavior, > especially when that behavior changes the common conception of how the > kernel performs its tasks. > I don't think that Linus Torvalds is ready to see the notion of thread id to invade the kernel (and I think he is right). The PID should be enough 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. Maybe, this should all be done in user space (comments Ulrich ?) by wrapping all system calls returning PID in their data. The main drawback I see for this is that each time a new system call return PID, the libpthread should also be aligned to wrap it. This is the reason why I think it is better to do this wrapping inside the kernel.
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).
-Eric +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE Web : http://www.ri.silicomp.com/~paire | Group SILICOMP - Research Institute Email: eric.paire@ri.silicomp.com | 2, avenue de Vignate Phone: +33 (0) 476 63 48 71 | F-38610 Gieres Fax : +33 (0) 476 51 05 32 | FRANCE
- 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/
| |