>> The "m" option is forced on, since the kernel does not have full
>> thread support. Threads look just like processes.
>> I'd like to fix this. At a very minimum, I need a way to identify
>> tasks that share address space. This is poor though, since I would
>> have to make ps sort processes by default. I think ps should be
>> somewhat fast by default.
> 1. I'm also interested in finding a way to identify threads sharing address
> spaces, which is why I recently posted an attempt at doing so. If you can
> propose soultions to the race pointed out by Alexander Viro, I'd be
Why worry? We have far more serious races with many other common
admin tools. Consider the "kill" command.
Fixing this might involve adding a unique ID to every part of the
process data, then eliminating the PID concept. That isn't UNIX.
UPID TTY TIME CMD
85e4a694805f3e2db8229f66bc289857 pts/2301 00:00:00 bash
c6064c9e596f9faa2891aaf1841ad5a8 pts/2301 00:18:21 a.out
3aeecde7313d3a9da0da507b29a90824 pts/2301 00:00:00 ps
$ kill -9 c6064c9e596f9faa2891aaf1841ad5a8
Now imagine every process having a dozen of those monster ID numbers.
There are IBM systems that do something like the above. They use a
set of letters carefully selected to avoid the chance of randomly
creating an obscene ID code.
> 2. What makes a shared address space the criteria for identifying
> different "threads" in a process? The Linux model is a lot more
> flexible than that, and I'd like to stick with that flexibility.
The Linux model can be annoyingly complex. I expect to see plenty of
problems as standards begin to define how tools interact with threads.
Normal process: does not use clone()
Threaded process: uses clone() via libc pthreads support
Strange process: uses clone() more directly
I mostly don't care how strange processes are displayed.
Every clone() flag greatly increases the number of strange types.
You could have horrid mixed processes, with a task that shares
signals with one task and filesystem actions with a different task.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/