>> 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
> grateful.
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.
$ ps
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/