Messages in this thread | | | Date | Wed, 18 Jan 2012 14:58:09 +0100 | From | Oleg Nesterov <> | Subject | Re: [RFC] fs, proc: Introduce /proc/<pid>/task/<tid>/children entry v6 |
| |
On 01/17, KOSAKI Motohiro wrote: > > (1/16/12 10:32 AM), Cyrill Gorcunov wrote: >> When we do checkpoint of a task we need to know the list of children >> the task, has but there is no easy and fast way to generate reverse >> parent->children chain from arbitrary<pid> (while a parent pid is >> provided in "PPid" field of /proc/<pid>/status). >> >> So instead of walking over all pids in the system (creating one big process >> tree in memory, just to figure out which children a task has) -- we add >> explicit /proc/<pid>/task/<tid>/children entry, because the kernel already has >> this kind of information but it is not yet exported. > > I doubt this is good idea. It move some complexity to userland, but not reduce. > Again, if we add this interface, it should help pstree like process traversal > tools. Bare task hierarchy shouldn't be exposed userland. I believe users need > sub process, not sub threads.
IOW, you mean that the reading from 'children' should list all children of the whole thread group. Yes, we discussed this before a bit.
In this case this file should live in /proc/pid/, not in /proc/pid/task/tid. But this doesn't allow to restore the hierarchy correctly, you need to know the parent thread. So I think /proc/pid/tasks/tid/children is still needed. And I think it does help pstree-like apps, just they need to look into task/.
As for /proc/pid/children, may be we can add it later. But this is not that simple. The problem is the threaded reparenting, we do not want to list the same child twice.
Oleg.
| |