For proper balance, normal processes need a single thread.
/proc/155/ Normal process
/proc/155/1 Thread #1 (same data as above)
/proc/200/ Threaded process (combined data?)
/proc/200/1 Thread #1
/proc/200/2 Thread #2
So for right now every process gets a "1" directory. It could be a
symlink to "." for now. (this is to be nice to future user-space
tools that expect threads)
To make threaded apps very compatible:
getpid() could return just the bottom 16 bits to make userspace
even more happy. Then a gettid() function gets the whole 32 bits.
Normal kill() handles both just fine.
> See above about how I'd like this to work. With the /proc/155/1
> setup, the old tools would only ever see the original parent,
> so to "ps" the threaded application would look like just one process.
They see what looks like a kernel memory leak.
(data is not summed up + some threads are hidden away)
> Additionally note that "kill -1 155" would send SIGHUP to _all_ the
> threads, and if you wanted to kill just one subthread you'd have to name
> it completely in 32 bits (ie "kill -1 $((0x10000+155))" would kill 155/1,
> and we'd probably make an extension to bash so that you can say just that:
> "kill -1 155/1" would do the math for you).
>
> Yes, this does imply that the first thread is special, but I don't see
> anything really wrong with that. If you don't want the first thread to
> be special, just don't use CLONE_PID - then all threads will have a
> full life of their own.
Symmetry requires numbering unthreaded processes from 0x10000.
They still show up with low numbers and can be killed with the
low numbers.
That gets rid of some special case code for thread #1.