KAMEZAWA Hiroyuki wrote: > On Wed, 18 Jun 2008 16:02:25 +0800 > Li Zefan <lizf@xxxxxxxxxxxxxx> wrote: > >> This control file is the equivalent of the "tasks" control file, but >> acting/reporting on entire thread groups. >> >> For example, we have a process with pid 1000 and its sub-thread with >> tid 1001, to attach them into a cgroup: >> # echo 1000 > procs >> Then show the process list and the task list respectively: >> # cat procs >> 1000 >> # cat tasks >> 1000 >> 1001 >> >> Questions: >> - What to do if the attaching of a thread failed? continue to attach >> other threads, or stop and return error? >> - When a sub-thread of a process is in the cgroup, but not its thread >> cgroup leader, what to do when 'cat procs'? just skip those threads? >> > I think this feature make sense. But not meets a theory that cgroup handles > a thread not a process. So, how about changing the definition of this interface > from > - showing procs > to > - showing threads which is thread-group-leader. > > One possible problem is a case that thread-group-leader exits while other > members are alive. In such case, thread-group-leader calls cgroup_exit() > but will be still alive until all sub-threads exit. So, this interface > cannot show correct information. > (right ??? please point out if I miss something) > It can show the thread group leader in zombie state with [TID]? > So, how about this kind of interface ? showing both of TID and PID. > > %/cat/procs > TID PID > 1001 1001 > 1234 1001 > 3856 1001 > 728 728 > .... > .... > > nonsense ? This information is also available from other means /proc/pid/tasks for example. I like Li's original interface for procs and tasks. I would also suggest adding groups. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers