Messages in this thread | | | Date | Sun, 19 Sep 2004 12:39:51 +0200 | From | Roger Luethi <> | Subject | Re: nproc: So? |
| |
On Sat, 18 Sep 2004 08:40:12 -0400, Albert Cahalan wrote: > To me, this looks like the killer feature. You could even > skip the regular process info. Simply return process identification > cookies that could be passed into a separate syscall to get > the information.
Do you mean "return cookies for all existing processes"? Or "return cookies for all processes created since X" (if so, what's X?) ?
> > True if you consider a static set of fields that never changes. Problematic > > otherwise, because as soon as you start grouping fields together, you need > > an agreement between kernel and user-space on the contents of these groups. > > I suppose this is small potatoes compared to the overhead > of dealing with ASCII, but individual field handling would > be a bit slower.
Correct.
> For initial libproc support, I'd start by requesting info > in groups that match what /proc provides today.
Makes perfect sense. You can pre-assemble an array of field IDs, hand them over to the kernel, and get the requested fields in the requested order.
> The stat() call simply fills in a struct. Given a per-process > cookie (or a PID if you tolerate the race conditions), a syscall > similar to stat() could fill in a struct.
With nproc as-is you can send a request that matches your desired struct and cast the result to a pointer to your struct.
An application can build its own cookie simply by always requesting a set of fields that _together_ can be used to identify a process. I reckon that PID + process creation timestamp would be a good combination (except that the latter is not currently available). The creation of the complete reply to a request is atomic per process, the race is gone. What is not possible right now is selecting processes based on a cookie -- the only selectors so far are "all of them" and "select by PID".
Roger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |