Re: linuxthreads and tid testing
Eric Paire (e.paire@opengroup.org)
Mon, 02 Aug 1999 08:28:10 +0200
> 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/