Re: linux-kernel-digest V1 #2693

Paul Barton-Davis (pbd@Op.Net)
Wed, 14 Oct 1998 21:47:54 -0300


>From: Pete Chown <Pete.Chown@skygate.co.uk>
>Date: Wed, 14 Oct 1998 09:07:52 +0000
>Subject: Re: "per-process" limits (was: Showstopper list)
>
>Incidentally the other problem in this area is that according to POSIX
>all threads should have the same pid. Apparently Linux does not do this
>at the moment because the CLONE_PID flag is not considered to be
>reliable. Does anyone know why it is not reliable, and what is involved
>in fixing it?

This is actually very complex. The problem arises from Linux'
conflation of a kernel thread ("task") with a process, despite the
existence of a system call (clone()) that violates this 1:1 mapping.

Because there is no "process" abstraction in Linux, only "tasks", and
because PID's for processes are required to be process-unique, using
CLONE_PID instantly violates all kinds of Unix semantics. For
instance, sending a signal to a given PID only kills the first such
task with that PID. You *could* fix each individual instance of this,
but the real problem is deeper.

>The other feature of NT that I quite like is fibres. A "fibre" is a
>user level thread which runs in one particular kernel level thread.
>This means that you have a choice of lightweight or heavyweight
>threads. Obviously both have advantages in different situations, and
>this system means that you can choose, or come up with a mixed scheme if
>that works better.

If my or some related attempt at "task groups" is ever incorporated,
you'll have all the flexibility in the world, since you can use your
own scheduler which can makes its own decisions (dynamic if necessary)
on how to map user threads onto kernel threads (within given group of
kernel threads (aka tasks)).

--p

-
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/