Re: Killing clones

H. Peter Anvin (hpa@transmeta.com)
14 Aug 1997 19:10:17 GMT

Followup to: <Pine.LNX.3.95.970814090203.21030C-100000@vuser.vu.union.edu>
By author: Rob Hagopian <hagopiar@vuser.vu.union.edu>
In newsgroup: linux.dev.kernel
>
> > About a year ago a least was a a discussion about fixing up the
> > CLONE_PID flag so that thread id's would be encoded in the upper bits of
> > the pid. One could have ps list only the proc info for the initial
> > thread (or other thread if the initial has exited), and be able to see
> > what initial process all the threads are associated with.
>
> So if 32-bit [real] PIDs come around (there was talk of them appearing in
> 2.1.x, and it's something I think a few people would like to see) then
> we'd have 48 or 64 bit PIDs with thread info?
> -Rob H.
>

Note: there is actually no need for tid's to be allocated from a
larger pool than pid's, although that may possibly allow some
optimizations (I am not 100% convinced, since I think the kernel would
have to validate all assumptions explicitly.)

You could very well allocate them out of the same number pool; if you
do *not* specify CLONE_PID then you allocate both a pid and a tid, if
you do, then you allocate a tid only. That would mean that tid's
wouldn't "look" any different than pid's, but the kernel would still
know.

For example: process - 47 threads - 48, 57, 122
process - 90 threads - 91, 94, 102, 107, 121
process - 92 threads - 93

(The last process being single-threaded.)

-hpa

-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
Always looking for a few good BOsFH.  **  Linux - the OS of global cooperation
        I am Baha'i -- ask me about it or see http://www.bahai.org/