Re: Process vs. Threads

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Hank Leininger writes:
> On 2001-03-07, "Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:

>> Then for proper ps and top output, you need a reasonably efficient
>> way to grab all threads as a group. This could be as simple as
>> ensuring that /proc directory reads return related tasks together.
>> This works too:   /proc/42/threads/98 -> ../../98
>
> For this (but not for other "proper thread support" things
> you mention) would it be enough to have /proc publish some token
> that represent unique ->fs, ->mm, etc pointers?  (The kernel-space
> address of each would work, though that might be leaking too much
> info; the least userspace must treat such values as opaque canary
> tokens.)  This does not give you the most efficient "ps --threads 231"
> but it does let ps, top, (fuser?), etc group processes with the
> same vm, files, etc, no?

You've identified the problem yourself.

When I wrote the new ps, I made a rule for myself: the default
output would not require sorting of any kind. Output would be
produced as soon as possible. This is for performance, and to
help tolerate kernel bugs that cause a hang.

So far I've resisted using threads myself to work around the
hang problem.

It won't be "ps --threads 231". It will be one of the following
options if you do want to see individual threads: m -m -T -L
(the options are in use on Tru64, AIX, IRIX, Solaris, UnixWare...)

So think of a way to wrap tasks together, preferably in a
way that is impossible for a non-POSIX thread to escape from.
Taking a guess at it:

Have an inherited task-group-ID that gets set equal to the task ID
whenever a task breaks away from other tasks. This includes fork(),
execve(), and any unshare() call that might be implemented. Note that
this does not, and indeed _must_ not, enforce POSIX signal behavior.
(the leader of a new and empty group might be able to request the
POSIX behavior for his group, but it can not be the default)