[PATCH 1/2] Adds a read-only "procs" file similar to "tasks" that shows only unique tgids
kamezawa.hiroyu at jp.fujitsu.com
Fri Jul 3 00:54:23 PDT 2009
On Thu, 2 Jul 2009 23:55:27 -0700
Andrew Morton <akpm at linux-foundation.org> wrote:
> On Thu, 2 Jul 2009 21:16:15 -0700 Paul Menage <menage at google.com> wrote:
> > On Thu, Jul 2, 2009 at 7:08 PM, Andrew Morton<akpm at linux-foundation.org> wrote:
> > >
> > > Why are we doing all this anyway? __To avoid presenting duplicated pids
> > > to userspace? __Nothing else?
> > To present the pids or tgids in sorted order. Removing duplicates is
> > only for the case of the "procs" file; that could certainly be left to
> > userspace, but it wouldn't by itself remove the existing requirement
> > for a contiguous array.
> > The seq_file iterator for these files relies on them being sorted so
> > that it can pick up where it left off even in the event of the pid set
> > changing between reads - it does a binary search to find the first pid
> > greater than the last one that was returned, so as to guarantee that
> > we return every pid that was in the cgroup before the scan started and
> > remained in the cgroup until after the scan finished; there are no
> > guarantees about pids that enter/leave the cgroup during the scan.
> OIC. Gee we made it hard for ourselves. That tears it.
At using "file" interface, it's not necessary to guarantee atomic-and-correct
result about list of pids. It's impossible.
readdir(/proc) does best-effort-jobs based on pids. plz do in such a way.
It uses find_ge_pid() to scanning all exisiting pids.
> > >
> > > btw, did pidlist_uniq() actually needs to allocate new memory for the
> > > output array? __Could it have done the filtering in-place?
> > Yes - or just omit duplicates in the seq_file iterator, I guess
> So now what? lib/dynarray.c?
We never need array for user interface, IIUC.
More information about the Containers