Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 21 Dec 2008 05:48:00 +0100
> From: "Roland Winkler" <Roland.Winkler@physik.uni-erlangen.de>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> 
> On Sun Dec 21 2008 Eli Zaretskii wrote:
> > Yes, but nobody said that looking at ppid you will have a proper
> > tree.
> 
> Under GNU/linux, the procps package contains not only the ps
> command. But it also contains the command pstree.

I don't see pstree in procps-3.2.7, perhaps I'm missing something.

> Though I didn't look at pstree's source code, I guess it is doing
> its job by analyzing ppid's.

I have no doubt that on GNU/Linux, a ppid of zero is a sign of the
root of the process tree.  But I wrote the 2 primitives that proced.el
uses in order to free proced.el of any such OS-dependent assumptions.
I have no problems with providing another one.

> Somehow I am missing the point here. Why do you think it is
> necessary or advantageous to have a separate primitive for that?

Because the implementation of such a predicate is inherently
OS-dependent, and I don't think proced.el (or any other Lisp program)
should know about how different OSes handle the root of their process
tree.

> Proced already provides a function proced-process-tree. It seems to
> me that all one needs for making this more robust is a more accurate
> rule of how system-process-attributes handles the ppid attribute in
> certain special cases.

A low-level primitive such as system-process-attributes should know
nothing about its users, ideally.  It should just return whatever the
OS tells it.  It should not adapt its handling of ppid to what its
callers might like or dislike.

> (And I expect that proced could easily work around in a robust way
> if no such rule was implemented. Simply, up to now I didn't worry
> about that when I wrote the proced code.)

I don't see how can you work around that without testing if you are on
windows-nt system or not.