* proced: ppid of process ID 0 can be 0
@ 2008-12-20 2:52 Juanma Barranquero
2008-12-20 3:27 ` Stefan Monnier
2008-12-20 11:34 ` Eli Zaretskii
0 siblings, 2 replies; 53+ messages in thread
From: Juanma Barranquero @ 2008-12-20 2:52 UTC (permalink / raw
To: Emacs Devel
proced.el assumes at several places (for example, at
`proced-filter-parents') that you can loop over the ppid, because
you'll eventually find a process with no parent.
That's not true with on Windows, where ppid (0) == 0. That causes a
stack failure, for example, if you hit RET (`proced-refine') over the
PPID of process 0.
I see two ways of fixing this: either removing the assumption from
proced.el, or forcing the Windows implementation of
system_process_attributes to adapt. First is more correct, second is
much easier (see tiny patch below).
Comments?
Juanma
Index: src/w32.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32.c,v
retrieving revision 1.157
diff -u -2 -r1.157 w32.c
--- src/w32.c 19 Dec 2008 19:50:39 -0000 1.157
+++ src/w32.c 20 Dec 2008 02:34:39 -0000
@@ -3886,7 +3886,8 @@
}
attrs = Fcons (Fcons (Qcomm, decoded_cmd), attrs);
- attrs = Fcons (Fcons (Qppid,
- make_fixnum_or_float (pe.th32ParentProcessID)),
- attrs);
+ if (proc_id != 0)
+ attrs = Fcons (Fcons (Qppid,
+ make_fixnum_or_float (pe.th32ParentProcessID)),
+ attrs);
attrs = Fcons (Fcons (Qpri, make_number (pe.pcPriClassBase)),
attrs);
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 2:52 proced: ppid of process ID 0 can be 0 Juanma Barranquero
@ 2008-12-20 3:27 ` Stefan Monnier
2008-12-20 4:31 ` Chong Yidong
2008-12-20 10:20 ` Juanma Barranquero
2008-12-20 11:34 ` Eli Zaretskii
1 sibling, 2 replies; 53+ messages in thread
From: Stefan Monnier @ 2008-12-20 3:27 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Emacs Devel
> + if (proc_id != 0)
Better test "proc_id != proc_id", I think.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 3:27 ` Stefan Monnier
@ 2008-12-20 4:31 ` Chong Yidong
2008-12-20 19:10 ` Stefan Monnier
2008-12-20 10:20 ` Juanma Barranquero
1 sibling, 1 reply; 53+ messages in thread
From: Chong Yidong @ 2008-12-20 4:31 UTC (permalink / raw
To: Stefan Monnier; +Cc: Juanma Barranquero, Emacs Devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> + if (proc_id != 0)
>
> Better test "proc_id != proc_id", I think.
Wait, what?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 3:27 ` Stefan Monnier
2008-12-20 4:31 ` Chong Yidong
@ 2008-12-20 10:20 ` Juanma Barranquero
1 sibling, 0 replies; 53+ messages in thread
From: Juanma Barranquero @ 2008-12-20 10:20 UTC (permalink / raw
To: Stefan Monnier; +Cc: Emacs Devel
On Sat, Dec 20, 2008 at 04:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Better test "proc_id != proc_id", I think.
You mean to test proc_id != parent_id, like in the patch below?
That's OK too, although I don't think a process other than 0 can have
itself as parent.
Juanma
Index: src/w32.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32.c,v
retrieving revision 1.157
diff -u -2 -r1.157 w32.c
--- src/w32.c 19 Dec 2008 19:50:39 -0000 1.157
+++ src/w32.c 20 Dec 2008 10:14:08 -0000
@@ -3886,7 +3886,8 @@
}
attrs = Fcons (Fcons (Qcomm, decoded_cmd), attrs);
- attrs = Fcons (Fcons (Qppid,
- make_fixnum_or_float (pe.th32ParentProcessID)),
- attrs);
+ if (proc_id != pe.th32ParentProcessID)
+ attrs = Fcons (Fcons (Qppid,
+ make_fixnum_or_float (pe.th32ParentProcessID)),
+ attrs);
attrs = Fcons (Fcons (Qpri, make_number (pe.pcPriClassBase)),
attrs);
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 2:52 proced: ppid of process ID 0 can be 0 Juanma Barranquero
2008-12-20 3:27 ` Stefan Monnier
@ 2008-12-20 11:34 ` Eli Zaretskii
2008-12-20 19:41 ` Roland Winkler
1 sibling, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-20 11:34 UTC (permalink / raw
To: Juanma Barranquero, Roland Winkler; +Cc: emacs-devel
> Date: Sat, 20 Dec 2008 03:52:40 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
>
> proced.el assumes at several places (for example, at
> `proced-filter-parents') that you can loop over the ppid, because
> you'll eventually find a process with no parent.
>
> That's not true with on Windows, where ppid (0) == 0. That causes a
> stack failure, for example, if you hit RET (`proced-refine') over the
> PPID of process 0.
>
> I see two ways of fixing this: either removing the assumption from
> proced.el, or forcing the Windows implementation of
> system_process_attributes to adapt. First is more correct, second is
> much easier (see tiny patch below).
I'd prefer that proced.el doesn't make such an unportable assumption.
Roland?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 4:31 ` Chong Yidong
@ 2008-12-20 19:10 ` Stefan Monnier
0 siblings, 0 replies; 53+ messages in thread
From: Stefan Monnier @ 2008-12-20 19:10 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, Emacs Devel
>>> + if (proc_id != 0)
>> Better test "proc_id != proc_id", I think.
> Wait, what?
Damn, that thing was potent!
Stef
PS: the intention was to compare the pid and the ppid.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 11:34 ` Eli Zaretskii
@ 2008-12-20 19:41 ` Roland Winkler
2008-12-20 21:02 ` Juanma Barranquero
2008-12-20 22:02 ` Eli Zaretskii
0 siblings, 2 replies; 53+ messages in thread
From: Roland Winkler @ 2008-12-20 19:41 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Juanma Barranquero, emacs-devel
On Sat Dec 20 2008 Eli Zaretskii wrote:
> > I see two ways of fixing this: either removing the assumption from
> > proced.el, or forcing the Windows implementation of
> > system_process_attributes to adapt. First is more correct, second is
> > much easier (see tiny patch below).
>
> I'd prefer that proced.el doesn't make such an unportable assumption.
I am not sure I get the point here. What is unportable where? I
mean, it seems to me that ultimately the solution is always the
same: when using the ppid attribute, one needs to make sure that it
is different from the corresponding pid. Or could one assign a
special meaning to the case that ppid=pid? There is no doubt that
proced assumes that ppid is always different from pid.
A comparison of ppid and pid can be implemented either on the level
of system_process_attributes. (I don't know whether for other
operating systems besides Windows we can have similar problems.) Or
it can be implemented inside proced. In the latter case, I would
implement the comparison of ppid and pid in
proced-process-attributes which is kind of the low-level function in
Proced calling system-process-attributes. (No other proced function
calls system-process-attributes.) So having the comparison of ppid
and pid in that function would work for proced for all operating
systems (requiring only a very small change in the code).
Yet anybody using system-process-attributes elsewhere might be
surprised that the return value of system-process-attributes can
give such meaningless results so that he/she probably would have to
implement the same check. So maybe for a clear definition of the
ppid attribute returned by system-process-attributes, we could
require that it must be different from pid.
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 19:41 ` Roland Winkler
@ 2008-12-20 21:02 ` Juanma Barranquero
2008-12-20 22:02 ` Eli Zaretskii
1 sibling, 0 replies; 53+ messages in thread
From: Juanma Barranquero @ 2008-12-20 21:02 UTC (permalink / raw
To: Roland Winkler; +Cc: Eli Zaretskii, emacs-devel
On Sat, Dec 20, 2008 at 20:41, Roland Winkler
<Roland.Winkler@physik.uni-erlangen.de> wrote:
> So maybe for a clear definition of the
> ppid attribute returned by system-process-attributes, we could
> require that it must be different from pid.
I agree.
If there were many platforms where ppid can be equal to pid, it would
make sense to generalize proced.el, but I don't think that's the case.
Juanma
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 19:41 ` Roland Winkler
2008-12-20 21:02 ` Juanma Barranquero
@ 2008-12-20 22:02 ` Eli Zaretskii
2008-12-20 22:41 ` Roland Winkler
2008-12-21 2:18 ` Stefan Monnier
1 sibling, 2 replies; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-20 22:02 UTC (permalink / raw
To: Roland Winkler; +Cc: lekktu, emacs-devel
> Date: Sat, 20 Dec 2008 20:41:20 +0100
> From: "Roland Winkler" <Roland.Winkler@physik.uni-erlangen.de>
> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
>
> > I'd prefer that proced.el doesn't make such an unportable assumption.
>
> I am not sure I get the point here. What is unportable where?
The assumption that going up the process tree will eventually find a
process that has no ppid attribute.
> I mean, it seems to me that ultimately the solution is always the
> same: when using the ppid attribute, one needs to make sure that it
> is different from the corresponding pid. Or could one assign a
> special meaning to the case that ppid=pid? There is no doubt that
> proced assumes that ppid is always different from pid.
Why do you need to assume that? Is that only to determine whether a
given process is the root of the process tree? If so, a more portable
way of doing that would be to have a primitive for that with a
system-dependent implementation.
If you need that assumption for something else, let's hear those other
reasons.
> Yet anybody using system-process-attributes elsewhere might be
> surprised that the return value of system-process-attributes can
> give such meaningless results
It is no more meaningless than having a process with no parent, IMO.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 22:02 ` Eli Zaretskii
@ 2008-12-20 22:41 ` Roland Winkler
2008-12-21 4:15 ` Eli Zaretskii
2008-12-21 2:18 ` Stefan Monnier
1 sibling, 1 reply; 53+ messages in thread
From: Roland Winkler @ 2008-12-20 22:41 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel
On Sun Dec 21 2008 Eli Zaretskii wrote:
> > I mean, it seems to me that ultimately the solution is always the
> > same: when using the ppid attribute, one needs to make sure that it
> > is different from the corresponding pid. Or could one assign a
> > special meaning to the case that ppid=pid? There is no doubt that
> > proced assumes that ppid is always different from pid.
>
> Why do you need to assume that? Is that only to determine whether a
> given process is the root of the process tree? If so, a more portable
> way of doing that would be to have a primitive for that with a
> system-dependent implementation.
It's the definition of a tree: when A points back to A, this doesn't
give a process tree. Of course, as I said, for Proced it is not so
important whether system-process-attributes can return a ppid that
equals pid or whether in this case it returns no ppid attribute
(or a ppid=0). It's easy to handle this case on te level of proced.
Yet the current discussion suggests to me that it would be
advantageous if the behavior of system-process-attributes was
documented for this case. It seems to me that the possiblities are:
- it may return a ppid that equals pid, so that one needs to handle
this case appropriately, if necessary, on the lisp level,
- it may return no ppid, if strictly speaking there is no parent
process
- it may return a ppid of zero, which is the current behavior under
GNU/linux
- some or all the above options are "legal" and its up to the user
to handle these possibilities appropriately
Is there any possiblity missing?
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 22:02 ` Eli Zaretskii
2008-12-20 22:41 ` Roland Winkler
@ 2008-12-21 2:18 ` Stefan Monnier
1 sibling, 0 replies; 53+ messages in thread
From: Stefan Monnier @ 2008-12-21 2:18 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland Winkler
>> > I'd prefer that proced.el doesn't make such an unportable assumption.
>> I am not sure I get the point here. What is unportable where?
> The assumption that going up the process tree will eventually find a
> process that has no ppid attribute.
I think it's a fine assumption. It is basically the same as saying that
the processes form a tree (or a forest), which is generally true, AFAIK.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-20 22:41 ` Roland Winkler
@ 2008-12-21 4:15 ` Eli Zaretskii
2008-12-21 4:48 ` Roland Winkler
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-21 4:15 UTC (permalink / raw
To: Roland Winkler; +Cc: lekktu, emacs-devel
> Date: Sat, 20 Dec 2008 23:41: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:
> > > I mean, it seems to me that ultimately the solution is always the
> > > same: when using the ppid attribute, one needs to make sure that it
> > > is different from the corresponding pid. Or could one assign a
> > > special meaning to the case that ppid=pid? There is no doubt that
> > > proced assumes that ppid is always different from pid.
> >
> > Why do you need to assume that? Is that only to determine whether a
> > given process is the root of the process tree? If so, a more portable
> > way of doing that would be to have a primitive for that with a
> > system-dependent implementation.
>
> It's the definition of a tree
Yes, but nobody said that looking at ppid you will have a proper tree.
> - it may return a ppid that equals pid, so that one needs to handle
> this case appropriately, if necessary, on the lisp level,
>
> - it may return no ppid, if strictly speaking there is no parent
> process
>
> - it may return a ppid of zero, which is the current behavior under
> GNU/linux
>
> - some or all the above options are "legal" and its up to the user
> to handle these possibilities appropriately
>
> Is there any possiblity missing?
Maybe not, but that's not what I was asking. I was asking why you
need the assumption about this behavior. I now understand that it is
only for handling processes as a tree. So I will write a primitive
for the root of that tree that Lisp code should use for such
decisions.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-21 4:15 ` Eli Zaretskii
@ 2008-12-21 4:48 ` Roland Winkler
2008-12-21 19:17 ` Eli Zaretskii
0 siblings, 1 reply; 53+ messages in thread
From: Roland Winkler @ 2008-12-21 4:48 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel
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. Though I didn't
look at pstree's source code, I guess it is doing its job by
analyzing ppid's.
Dan Nicolaescu had suggested ("wishlist") that it would be nice to
have an emacs/proced implementation of pstree. I guess he is right.
Often it might be much easier to manipulate processes if proced
didn't present the processes in some linear order; but instead it
made the tree structure with parents and children transparent.
> > Is there any possiblity missing?
>
> Maybe not, but that's not what I was asking. I was asking why you
> need the assumption about this behavior. I now understand that it is
> only for handling processes as a tree. So I will write a primitive
> for the root of that tree that Lisp code should use for such
> decisions.
Somehow I am missing the point here. Why do you think it is
necessary or advantageous to have a separate primitive for that?
Isn't it more transparent to implement this on the lisp level?
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. (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.)
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-21 4:48 ` Roland Winkler
@ 2008-12-21 19:17 ` Eli Zaretskii
2008-12-21 21:26 ` Juanma Barranquero
` (2 more replies)
0 siblings, 3 replies; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-21 19:17 UTC (permalink / raw
To: Roland Winkler; +Cc: lekktu, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-21 19:17 ` Eli Zaretskii
@ 2008-12-21 21:26 ` Juanma Barranquero
2008-12-22 4:09 ` Eli Zaretskii
2008-12-22 2:45 ` Stefan Monnier
2008-12-22 8:28 ` Ulrich Mueller
2 siblings, 1 reply; 53+ messages in thread
From: Juanma Barranquero @ 2008-12-21 21:26 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, Roland Winkler
On Sun, Dec 21, 2008 at 20:17, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.
That is true. OTOH, your approach can also be evaluated by weighting
the complexity it introduces (however small) against the uncleanliness
of adapting one current primitive to cater to expectations. I'd be
more convinced that your generalization is useful if we had many
different platform-dependent implementations, but that does not seem
likely.
Juanma
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-21 19:17 ` Eli Zaretskii
2008-12-21 21:26 ` Juanma Barranquero
@ 2008-12-22 2:45 ` Stefan Monnier
2008-12-22 4:08 ` Eli Zaretskii
2008-12-22 8:28 ` Ulrich Mueller
2 siblings, 1 reply; 53+ messages in thread
From: Stefan Monnier @ 2008-12-22 2:45 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland Winkler
> 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.
The primitives should ensure that what they return forms a forest.
I.e. under POSIX, they should treat a "ppid == 0" as meaning that
there's no parent (i.e. the data returned to Elisp should never say "the
parent is process 0" but should instead say "this process doesn't have
a parent").
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 2:45 ` Stefan Monnier
@ 2008-12-22 4:08 ` Eli Zaretskii
2008-12-22 4:17 ` Miles Bader
` (3 more replies)
0 siblings, 4 replies; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-22 4:08 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, emacs-devel, Roland.Winkler
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>, lekktu@gmail.com, emacs-devel@gnu.org
> Date: Sun, 21 Dec 2008 21:45:06 -0500
>
> The primitives should ensure that what they return forms a forest.
You mean a tree.
> I.e. under POSIX, they should treat a "ppid == 0" as meaning that
> there's no parent (i.e. the data returned to Elisp should never say "the
> parent is process 0" but should instead say "this process doesn't have
> a parent").
For me, code that calls process-tree-root-p (say) is much more
self-explanatory than a test for a missing parent pid attribute. It
is also more reliable, since ppid attribute could be missing for some
other reason, like failure to access the attribute.
So I don't understand why you insist on the above, please feel free to
explain what advantages do you see there.
Btw, is the above really mandated by Posix? Any references to that?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-21 21:26 ` Juanma Barranquero
@ 2008-12-22 4:09 ` Eli Zaretskii
2008-12-22 10:41 ` Juanma Barranquero
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-22 4:09 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Roland.Winkler, emacs-devel
> Date: Sun, 21 Dec 2008 22:26:15 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org, Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>
>
> OTOH, your approach can also be evaluated by weighting the
> complexity it introduces (however small) against the uncleanliness
> of adapting one current primitive to cater to expectations.
I see no complexity at all. Please tell what is complex about another
primitive.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 4:08 ` Eli Zaretskii
@ 2008-12-22 4:17 ` Miles Bader
2008-12-22 19:10 ` Eli Zaretskii
2008-12-22 8:54 ` Harald Hanche-Olsen
` (2 subsequent siblings)
3 siblings, 1 reply; 53+ messages in thread
From: Miles Bader @ 2008-12-22 4:17 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, Roland.Winkler, Stefan Monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> So I don't understand why you insist on the above, please feel free to
> explain what advantages do you see there.
More elegant, less confusing than a "magic" value for the ppid.
-Miles
--
I'd rather be consing.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-21 19:17 ` Eli Zaretskii
2008-12-21 21:26 ` Juanma Barranquero
2008-12-22 2:45 ` Stefan Monnier
@ 2008-12-22 8:28 ` Ulrich Mueller
2 siblings, 0 replies; 53+ messages in thread
From: Ulrich Mueller @ 2008-12-22 8:28 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland Winkler
>>>>> On Sun, 21 Dec 2008, Eli Zaretskii wrote:
>> 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.
You aren't. pstree is part of the psmisc package.
<http://psmisc.sourceforge.net/>
>> Though I didn't look at pstree's source code, I guess it is doing
>> its job by analyzing ppid's.
It does.
Ulrich
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 4:08 ` Eli Zaretskii
2008-12-22 4:17 ` Miles Bader
@ 2008-12-22 8:54 ` Harald Hanche-Olsen
2008-12-22 10:43 ` Juanma Barranquero
2008-12-22 10:59 ` Andreas Schwab
2008-12-22 12:23 ` Stefan Monnier
3 siblings, 1 reply; 53+ messages in thread
From: Harald Hanche-Olsen @ 2008-12-22 8:54 UTC (permalink / raw
To: emacs-devel
+ Eli Zaretskii <eliz@gnu.org>:
>> I.e. under POSIX, they should treat a "ppid == 0" as meaning that
>> there's no parent (i.e. the data returned to Elisp should never say "the
>> parent is process 0" but should instead say "this process doesn't have
>> a parent").
>
> [...]
>
> Btw, is the above really mandated by Posix? Any references to that?
FWIW, on FreeBSD there is process 0 (the swapper), and various kernel
processes have process 0 as their parent.
; pstree 0
-+= 00000 root [swapper]
|-+= 00001 root /sbin/init --
| |--= 00354 _dhcp dhclient: em0 (dhclient)
| |--= 00623 root /sbin/devd
.... <snip> ....
|--- 00002 root [g_event]
|--- 00003 root [g_up]
|--- 00004 root [g_down]
|--- 00005 root [system_taskq]
|--- 00006 root [system_taskq]
|--- 00007 root [acpi_task_0]
.... <snipetty snip> ....
Of course, it may be that you really don't want emacs to see kernel
processes at all.
- Harald
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 4:09 ` Eli Zaretskii
@ 2008-12-22 10:41 ` Juanma Barranquero
2008-12-22 19:17 ` Eli Zaretskii
0 siblings, 1 reply; 53+ messages in thread
From: Juanma Barranquero @ 2008-12-22 10:41 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Roland.Winkler, emacs-devel
On Mon, Dec 22, 2008 at 05:09, Eli Zaretskii <eliz@gnu.org> wrote:
> I see no complexity at all. Please tell what is complex about another
> primitive.
Lines of code, for starters. And the need to document it, even if only
in a comment or a docstring.
Which is much more worthwhile if the primitive is generally useful.
Juanma
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 8:54 ` Harald Hanche-Olsen
@ 2008-12-22 10:43 ` Juanma Barranquero
2008-12-22 10:50 ` Harald Hanche-Olsen
2008-12-22 18:03 ` Giorgos Keramidas
0 siblings, 2 replies; 53+ messages in thread
From: Juanma Barranquero @ 2008-12-22 10:43 UTC (permalink / raw
To: Harald Hanche-Olsen; +Cc: emacs-devel
On Mon, Dec 22, 2008 at 09:54, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:
> FWIW, on FreeBSD there is process 0 (the swapper), and various kernel
> processes have process 0 as their parent.
There's no problem with a process having ppid = 0. But there's a
problem with processes having ppid = pid. Is that the case in FreeBSD?
Juanma
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 10:43 ` Juanma Barranquero
@ 2008-12-22 10:50 ` Harald Hanche-Olsen
2008-12-22 18:03 ` Giorgos Keramidas
1 sibling, 0 replies; 53+ messages in thread
From: Harald Hanche-Olsen @ 2008-12-22 10:50 UTC (permalink / raw
To: emacs-devel
+ "Juanma Barranquero" <lekktu@gmail.com>:
> There's no problem with a process having ppid = 0. But there's a
> problem with processes having ppid = pid. Is that the case in FreeBSD?
Apparently it is:
; ps -o pid,ppid,command 0
PID PPID COMMAND
0 0 [swapper]
- Harald
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 4:08 ` Eli Zaretskii
2008-12-22 4:17 ` Miles Bader
2008-12-22 8:54 ` Harald Hanche-Olsen
@ 2008-12-22 10:59 ` Andreas Schwab
2008-12-22 19:22 ` Eli Zaretskii
2008-12-22 12:23 ` Stefan Monnier
3 siblings, 1 reply; 53+ messages in thread
From: Andreas Schwab @ 2008-12-22 10:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, Roland.Winkler, Stefan Monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>, lekktu@gmail.com, emacs-devel@gnu.org
>> Date: Sun, 21 Dec 2008 21:45:06 -0500
>>
>> The primitives should ensure that what they return forms a forest.
>
> You mean a tree.
There are at least two process trees in modern Linux: one tree rooted at
init (pid 1) and another one rooted at kthreadd (the mother of all
kernel threads).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 4:08 ` Eli Zaretskii
` (2 preceding siblings ...)
2008-12-22 10:59 ` Andreas Schwab
@ 2008-12-22 12:23 ` Stefan Monnier
2008-12-22 19:57 ` Eli Zaretskii
3 siblings, 1 reply; 53+ messages in thread
From: Stefan Monnier @ 2008-12-22 12:23 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland.Winkler
>> The primitives should ensure that what they return forms a forest.
> You mean a tree.
No, I meant a forest. It may consist of a single tree, but I see no
reason to impose such a constraint.
>> I.e. under POSIX, they should treat a "ppid == 0" as meaning that
>> there's no parent (i.e. the data returned to Elisp should never say "the
>> parent is process 0" but should instead say "this process doesn't have
>> a parent").
> For me, code that calls process-tree-root-p (say) is much more
> self-explanatory than a test for a missing parent pid attribute.
To me the definition of "root" is "has no parent", so the two are
equivalent. I could live with a predicate process-tree-root-p, but I'd
expect it to just check for the absence of a parent.
> It is also more reliable, since ppid attribute could be missing for
> some other reason, like failure to access the attribute.
And what would your process-tree-root-p say in that case?
> Btw, is the above really mandated by Posix? Any references to that?
I don't know, but whatever it is POSIX say, it should be handled in the
POSIX implementation of system-process-attributes.
On my GNU/Linux system, 0 is not a process, so a ppid of 0 is not
a parent but rather the mark of the absence of a parent.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 10:43 ` Juanma Barranquero
2008-12-22 10:50 ` Harald Hanche-Olsen
@ 2008-12-22 18:03 ` Giorgos Keramidas
1 sibling, 0 replies; 53+ messages in thread
From: Giorgos Keramidas @ 2008-12-22 18:03 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Harald Hanche-Olsen, emacs-devel
On Mon, 22 Dec 2008 11:43:15 +0100, "Juanma Barranquero" <lekktu@gmail.com> wrote:
> On Mon, Dec 22, 2008 at 09:54, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:
>
>> FWIW, on FreeBSD there is process 0 (the swapper), and various kernel
>> processes have process 0 as their parent.
>
> There's no problem with a process having ppid = 0. But there's a
> problem with processes having ppid = pid. Is that the case in FreeBSD?
Yes this is the case:
$ ps -xao pid,ppid,args | sed -n -e 1p -e /sed/d -e /kernel/p
PID PPID COMMAND
0 0 [kernel]
$
There are several processes with ppid == 0, and process 0 has pid == ppid:
PID PPID COMMAND
0 0 [kernel]
1 0 /sbin/init --
2 0 [g_event]
3 0 [g_up]
4 0 [g_down]
5 0 [xpt_thrd]
6 0 [sctp_iterator]
7 0 [pfpurge]
8 0 [pagedaemon]
9 0 [vmdaemon]
10 0 [audit]
11 0 [idle]
12 0 [intr]
13 0 [yarrow]
14 0 [usb0]
15 0 [usbtask-hc]
16 0 [usbtask-dr]
17 0 [usb1]
18 0 [usb2]
19 0 [usb3]
20 0 [usb4]
21 0 [usb5]
22 0 [usb6]
23 0 [acpi_thermal]
24 0 [acpi_cooling0]
25 0 [pagezero]
26 0 [bufdaemon]
27 0 [vnlru]
28 0 [syncer]
29 0 [softdepflush]
1019 0 [md0]
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 4:17 ` Miles Bader
@ 2008-12-22 19:10 ` Eli Zaretskii
0 siblings, 0 replies; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-22 19:10 UTC (permalink / raw
To: Miles Bader; +Cc: lekktu, emacs-devel, monnier, Roland.Winkler
> From: Miles Bader <miles@gnu.org>
> Date: Mon, 22 Dec 2008 13:17:15 +0900
> Cc: lekktu@gmail.com, Roland.Winkler@physik.uni-erlangen.de,
> Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org> writes:
> > So I don't understand why you insist on the above, please feel free to
> > explain what advantages do you see there.
>
> More elegant, less confusing than a "magic" value for the ppid.
But I wasn't suggesting to use magic values. You confused me with
someone else. I was suggesting a primitive, so that Lisp code will
be oblivious as to how tree root is determined.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 10:41 ` Juanma Barranquero
@ 2008-12-22 19:17 ` Eli Zaretskii
2008-12-22 19:26 ` Juanma Barranquero
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-22 19:17 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Roland.Winkler, emacs-devel
> Date: Mon, 22 Dec 2008 11:41:22 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org, Roland.Winkler@physik.uni-erlangen.de
>
> Which is much more worthwhile if the primitive is generally useful.
Judging by the latest posts, there seems to be at least one more OS
where the Linux logic will not work, unless I'm mistaken.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 10:59 ` Andreas Schwab
@ 2008-12-22 19:22 ` Eli Zaretskii
2008-12-22 19:37 ` David De La Harpe Golden
2008-12-22 19:59 ` Andreas Schwab
0 siblings, 2 replies; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-22 19:22 UTC (permalink / raw
To: Andreas Schwab; +Cc: lekktu, Roland.Winkler, monnier, emacs-devel
> From: Andreas Schwab <schwab@suse.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, lekktu@gmail.com,
> emacs-devel@gnu.org, Roland.Winkler@physik.uni-erlangen.de
> Date: Mon, 22 Dec 2008 11:59:37 +0100
>
> There are at least two process trees in modern Linux: one tree rooted at
> init (pid 1) and another one rooted at kthreadd (the mother of all
> kernel threads).
On this system:
Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006 x86_64 GNU/Linux
I don't see a kthreadd process. I only see a kthread (one d) which is
a child of init. Is this because this system is not modern enough?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 19:17 ` Eli Zaretskii
@ 2008-12-22 19:26 ` Juanma Barranquero
0 siblings, 0 replies; 53+ messages in thread
From: Juanma Barranquero @ 2008-12-22 19:26 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Roland.Winkler, emacs-devel
> Judging by the latest posts, there seems to be at least one more OS
> where the Linux logic will not work, unless I'm mistaken.
Apparently so, yes.
Well, IMHO the situation does not merit introducing a primitive for
it, but of course I'm not going to oppose it, either. In fact, looking
for a function to find the root of a process tree was the reason I
discovered the problem in proced in the first place...
Juanma
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 19:22 ` Eli Zaretskii
@ 2008-12-22 19:37 ` David De La Harpe Golden
2008-12-22 19:59 ` Andreas Schwab
1 sibling, 0 replies; 53+ messages in thread
From: David De La Harpe Golden @ 2008-12-22 19:37 UTC (permalink / raw
To: Eli Zaretskii
Cc: Andreas Schwab, Roland.Winkler, emacs-devel, monnier, lekktu
Eli Zaretskii wrote:
> I don't see a kthreadd process. I only see a kthread (one d) which is
> a child of init. Is this because this system is not modern enough?
>
>
On my 2.6.26 system, I have an init (pid 1, ppid 0) and a
[kthreadd] (pid 2, ppid 0), according to ps ajx
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 12:23 ` Stefan Monnier
@ 2008-12-22 19:57 ` Eli Zaretskii
2008-12-22 22:24 ` Stefan Monnier
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-22 19:57 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, emacs-devel, Roland.Winkler
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de, lekktu@gmail.com, emacs-devel@gnu.org
> Date: Mon, 22 Dec 2008 07:23:05 -0500
>
> To me the definition of "root" is "has no parent", so the two are
> equivalent.
Same here. But "having no parent" and "found zero in /proc/NNN/stat"
is not necessarily the same.
> I could live with a predicate process-tree-root-p, but I'd expect it
> to just check for the absence of a parent.
Me too. However, that check is OS-dependent, so I don't think it
should be in Lisp.
> > It is also more reliable, since ppid attribute could be missing for
> > some other reason, like failure to access the attribute.
>
> And what would your process-tree-root-p say in that case?
It depends on the OS.
> On my GNU/Linux system, 0 is not a process, so a ppid of 0 is not
> a parent but rather the mark of the absence of a parent.
Sounds like this isn't true on FreeBSD as well, not only on
MS-Windows.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 19:22 ` Eli Zaretskii
2008-12-22 19:37 ` David De La Harpe Golden
@ 2008-12-22 19:59 ` Andreas Schwab
1 sibling, 0 replies; 53+ messages in thread
From: Andreas Schwab @ 2008-12-22 19:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, Roland.Winkler, monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> On this system:
>
> Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006 x86_64 GNU/Linux
>
> I don't see a kthreadd process.
It was added in v2.6.22-rc1 (1½ years ago).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 19:57 ` Eli Zaretskii
@ 2008-12-22 22:24 ` Stefan Monnier
2008-12-23 4:02 ` Eli Zaretskii
0 siblings, 1 reply; 53+ messages in thread
From: Stefan Monnier @ 2008-12-22 22:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland.Winkler
>> To me the definition of "root" is "has no parent", so the two are
>> equivalent.
> Same here. But "having no parent" and "found zero in /proc/NNN/stat"
> is not necessarily the same.
>> I could live with a predicate process-tree-root-p, but I'd expect it
>> to just check for the absence of a parent.
> Me too. However, that check is OS-dependent, so I don't think it
> should be in Lisp.
Indeed, it should be in system-process-attributes which is already
OS-dependent.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-22 22:24 ` Stefan Monnier
@ 2008-12-23 4:02 ` Eli Zaretskii
2008-12-23 12:28 ` Roland Winkler
2008-12-23 14:44 ` Stefan Monnier
0 siblings, 2 replies; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-23 4:02 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, emacs-devel, Roland.Winkler
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de, lekktu@gmail.com, emacs-devel@gnu.org
> Date: Mon, 22 Dec 2008 17:24:24 -0500
>
> >> To me the definition of "root" is "has no parent", so the two are
> >> equivalent.
> > Same here. But "having no parent" and "found zero in /proc/NNN/stat"
> > is not necessarily the same.
> >> I could live with a predicate process-tree-root-p, but I'd expect it
> >> to just check for the absence of a parent.
> > Me too. However, that check is OS-dependent, so I don't think it
> > should be in Lisp.
>
> Indeed, it should be in system-process-attributes which is already
> OS-dependent.
If you mean by having no ppid attribute, then that's ambiguous, since
an attribute can be missing because it is inaccessible for some
reason, like some kind of failure unrelated to the fact that the
process is really a root of a tree.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-23 4:02 ` Eli Zaretskii
@ 2008-12-23 12:28 ` Roland Winkler
2008-12-23 14:44 ` Stefan Monnier
1 sibling, 0 replies; 53+ messages in thread
From: Roland Winkler @ 2008-12-23 12:28 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, Stefan Monnier, emacs-devel
> > Indeed, it should be in system-process-attributes which is already
> > OS-dependent.
>
> If you mean by having no ppid attribute, then that's ambiguous, since
> an attribute can be missing because it is inaccessible for some
> reason, like some kind of failure unrelated to the fact that the
> process is really a root of a tree.
I was offline for a few days. In my humble opinion, the behavior of
pstree is really exactly what I would find useful from a practical
point of view. Pstree's man page says:
pstree shows running processes as a tree. The tree is rooted at
either pid or init if pid is omitted. If a user name is specified,
all process trees rooted at processes owned by that user are
shown.
Unless I am overlooking something, this means that within a list of
processes (say, the processes owned by $USER or root), *a* root is a
process that doesn't have a parent process within the given list of
processes. This implies that one can get several distinct process
trees from one list of processes. For example, on my GNU/linux system:
- For `pstree 1', the process tree starts with init.
- `pstree 2' shows kthreadd and its children
- Both root and kthreadd have ppid 0. But `pstree 0' gives an error.
- `pstree $USER' gives many unrelated trees, that is, for pstree
there is generally no such thing like `the' root of `the' process
tree.
- `pstree root' seems to be a minor inconsistency as it is
equivalent to `pstree 1'. It seems to ignore the process tree
rooted in kthreadd.
All this behavior is currently implemented in proced-process-tree
with the only bug that it yields an infinite recursion if
according to system-process-attributes a process is its own parent.
(I guess it is fine that system-process-attributes always reports
the ppid it gets from the OS. An application like proced can handle
such special cases easily.)
Having read the recent contributions to this thread I do not see why
anything more sophisticated could be useful. For all useful
scenarios I can envision, the ppid attribute of
system-process-attributes is all that is needed. To consider process
B the child of process A it is necessary that B has the ppid
attribute with a value that is the pid of A. Any other case (ppid
attribute absent, having a value that points to a nonexistent
process or whatever) doesn't allow one to put A and B one above each
other in a process tree, so it seems to me that it's not worth the
effort to worry about the details in emacs.
Though I didn't read the code of pstree in detail, I'd be very
surprised if it used a more sophisticated scheme.
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-23 4:02 ` Eli Zaretskii
2008-12-23 12:28 ` Roland Winkler
@ 2008-12-23 14:44 ` Stefan Monnier
2008-12-23 19:12 ` Eli Zaretskii
1 sibling, 1 reply; 53+ messages in thread
From: Stefan Monnier @ 2008-12-23 14:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland.Winkler
>> Indeed, it should be in system-process-attributes which is already
>> OS-dependent.
> If you mean by having no ppid attribute, then that's ambiguous, since
> an attribute can be missing because it is inaccessible for some
> reason, like some kind of failure unrelated to the fact that the
> process is really a root of a tree.
Seems very hypothetical. And on top of that, even in that hypothetical
case, it's far from clear that it would create any problem. More to the
point: even if we could distinguish the "no ppid" from "unkown ppid",
it's unclear how Elisp code could make use of it. So I think we
shouldn't worry about it.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-23 14:44 ` Stefan Monnier
@ 2008-12-23 19:12 ` Eli Zaretskii
2008-12-23 20:41 ` Stefan Monnier
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-23 19:12 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, emacs-devel, Roland.Winkler
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de, lekktu@gmail.com, emacs-devel@gnu.org
> Date: Tue, 23 Dec 2008 09:44:29 -0500
>
> >> Indeed, it should be in system-process-attributes which is already
> >> OS-dependent.
> > If you mean by having no ppid attribute, then that's ambiguous, since
> > an attribute can be missing because it is inaccessible for some
> > reason, like some kind of failure unrelated to the fact that the
> > process is really a root of a tree.
>
> Seems very hypothetical.
It's not hypothetical, I've seen such cases and reported them to
Roland.
> More to the point: even if we could distinguish the "no ppid" from
> "unkown ppid", it's unclear how Elisp code could make use of it.
Lisp code cannot, but a primitive written in C can.
But we are repeating ourselves.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-23 19:12 ` Eli Zaretskii
@ 2008-12-23 20:41 ` Stefan Monnier
2008-12-23 22:34 ` Giorgos Keramidas
2008-12-24 4:15 ` Eli Zaretskii
0 siblings, 2 replies; 53+ messages in thread
From: Stefan Monnier @ 2008-12-23 20:41 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland.Winkler
>> >> Indeed, it should be in system-process-attributes which is already
>> >> OS-dependent.
>> > If you mean by having no ppid attribute, then that's ambiguous, since
>> > an attribute can be missing because it is inaccessible for some
>> > reason, like some kind of failure unrelated to the fact that the
>> > process is really a root of a tree.
>> Seems very hypothetical.
> It's not hypothetical, I've seen such cases and reported them to
> Roland.
What were those cases?
>> More to the point: even if we could distinguish the "no ppid" from
>> "unkown ppid", it's unclear how Elisp code could make use of it.
> Lisp code cannot, but a primitive written in C can.
Like what can it do?
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-23 20:41 ` Stefan Monnier
@ 2008-12-23 22:34 ` Giorgos Keramidas
2008-12-24 2:34 ` Stefan Monnier
2008-12-24 4:15 ` Eli Zaretskii
1 sibling, 1 reply; 53+ messages in thread
From: Giorgos Keramidas @ 2008-12-23 22:34 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, Eli Zaretskii, Roland.Winkler, emacs-devel
On Tue, 23 Dec 2008 15:41:56 -0500, Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:
>>> >> Indeed, it should be in system-process-attributes which is already
>>> >> OS-dependent.
>>> > If you mean by having no ppid attribute, then that's ambiguous, since
>>> > an attribute can be missing because it is inaccessible for some
>>> > reason, like some kind of failure unrelated to the fact that the
>>> > process is really a root of a tree.
>>>
>>> Seems very hypothetical.
>>
>> It's not hypothetical, I've seen such cases and reported them to
>> Roland.
>
> What were those cases?
>
>>> More to the point: even if we could distinguish the "no ppid" from
>>> "unkown ppid", it's unclear how Elisp code could make use of it.
>> Lisp code cannot, but a primitive written in C can.
>
> Like what can it do?
It can differentiate between FreeBSD 4.3 and FreeBSD 7.2 if they use a
different style of `process root', or between Linux 1.2.X, 2.4.X and
2.6.X. Right now, Emacs sets `system-type' to "berkeley-unix" on more
than one BSD system. They might be easier to detect at C level.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-23 22:34 ` Giorgos Keramidas
@ 2008-12-24 2:34 ` Stefan Monnier
2008-12-24 4:14 ` Eli Zaretskii
0 siblings, 1 reply; 53+ messages in thread
From: Stefan Monnier @ 2008-12-24 2:34 UTC (permalink / raw
To: Giorgos Keramidas; +Cc: lekktu, Eli Zaretskii, Roland.Winkler, emacs-devel
>>>> More to the point: even if we could distinguish the "no ppid" from
>>>> "unkown ppid", it's unclear how Elisp code could make use of it.
>>> Lisp code cannot, but a primitive written in C can.
>>
>> Like what can it do?
> It can differentiate between FreeBSD 4.3 and FreeBSD 7.2 if they use a
> different style of `process root', or between Linux 1.2.X, 2.4.X and
> 2.6.X. Right now, Emacs sets `system-type' to "berkeley-unix" on more
> than one BSD system. They might be easier to detect at C level.
That's not what I'm asking. I'm asking: what can C code (or Elisp code
for that matter) do when the ppid is somehow not found (i.e. there's no
ppid available, but the process might have a parent).
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-24 2:34 ` Stefan Monnier
@ 2008-12-24 4:14 ` Eli Zaretskii
2008-12-24 16:47 ` Stefan Monnier
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-24 4:14 UTC (permalink / raw
To: Stefan Monnier; +Cc: keramida, lekktu, Roland.Winkler, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, lekktu@gmail.com, emacs-devel@gnu.org, Roland.Winkler@physik.uni-erlangen.de
> Date: Tue, 23 Dec 2008 21:34:56 -0500
>
> >>>> More to the point: even if we could distinguish the "no ppid" from
> >>>> "unkown ppid", it's unclear how Elisp code could make use of it.
> >>> Lisp code cannot, but a primitive written in C can.
> >>
> >> Like what can it do?
>
> > It can differentiate between FreeBSD 4.3 and FreeBSD 7.2 if they use a
> > different style of `process root', or between Linux 1.2.X, 2.4.X and
> > 2.6.X. Right now, Emacs sets `system-type' to "berkeley-unix" on more
> > than one BSD system. They might be easier to detect at C level.
>
> That's not what I'm asking. I'm asking: what can C code (or Elisp code
> for that matter) do when the ppid is somehow not found (i.e. there's no
> ppid available, but the process might have a parent).
The process-tree-root-p primitive does not need to employ the same
logic (nor even the same syscalls, actually) that
system-process-attributes does. The latter simply omits from the
alist it returns any attribute that it could not fetch for some
reason, any reason. The former could do something else. What
exactly, I will figure out when I write it.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-23 20:41 ` Stefan Monnier
2008-12-23 22:34 ` Giorgos Keramidas
@ 2008-12-24 4:15 ` Eli Zaretskii
2008-12-24 16:47 ` Stefan Monnier
1 sibling, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-24 4:15 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, emacs-devel, Roland.Winkler
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Roland.Winkler@physik.uni-erlangen.de, lekktu@gmail.com,
> emacs-devel@gnu.org
> Date: Tue, 23 Dec 2008 15:41:56 -0500
>
> >> >> Indeed, it should be in system-process-attributes which is already
> >> >> OS-dependent.
> >> > If you mean by having no ppid attribute, then that's ambiguous, since
> >> > an attribute can be missing because it is inaccessible for some
> >> > reason, like some kind of failure unrelated to the fact that the
> >> > process is really a root of a tree.
> >> Seems very hypothetical.
> > It's not hypothetical, I've seen such cases and reported them to
> > Roland.
>
> What were those cases?
Processes that disappeared while Emacs was reading /proc, for example.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
@ 2008-12-24 7:42 grischka
0 siblings, 0 replies; 53+ messages in thread
From: grischka @ 2008-12-24 7:42 UTC (permalink / raw
To: monnier; +Cc: emacs-devel
> That's not what I'm asking. I'm asking: what can C code (or
> Elisp code or that matter) do when the ppid is somehow not
> found (i.e. there's no ppid available, but the process might
> have a parent).
Well, for example:
(when
(although
(maybe-not (process-tree-root-p pid))
(somehow-not-found-p (process-parent pid))
)
(with the-thing
(begin-to-believe
(if (y-or-n-p "Continue? ") 'funny 'strange)
)))
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-24 4:15 ` Eli Zaretskii
@ 2008-12-24 16:47 ` Stefan Monnier
2008-12-24 18:29 ` Eli Zaretskii
0 siblings, 1 reply; 53+ messages in thread
From: Stefan Monnier @ 2008-12-24 16:47 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland.Winkler
>> > It's not hypothetical, I've seen such cases and reported them to
>> > Roland.
>> What were those cases?
> Processes that disappeared while Emacs was reading /proc, for example.
Then don't return them at all rather than returning them with
incomplete data.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-24 4:14 ` Eli Zaretskii
@ 2008-12-24 16:47 ` Stefan Monnier
0 siblings, 0 replies; 53+ messages in thread
From: Stefan Monnier @ 2008-12-24 16:47 UTC (permalink / raw
To: Eli Zaretskii; +Cc: keramida, lekktu, Roland.Winkler, emacs-devel
> The process-tree-root-p primitive does not need to employ the same
> logic (nor even the same syscalls, actually) that
> system-process-attributes does. The latter simply omits from the
> alist it returns any attribute that it could not fetch for some
> reason, any reason. The former could do something else. What
> exactly, I will figure out when I write it.
So you're saying that by working hard you can maybe in some corner case
give a more precise answer for the boolean `process-tree-root-p' while
the parent process is not returned by `system-process-attributes'.
I can't think of any situation where process-tree-root-p would be useful
and where the ppids wouldn't be needed.
I also still have no idea how/when system-process-attributes could fail
to return ppids.
It still sounds terribly far fetched.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-24 16:47 ` Stefan Monnier
@ 2008-12-24 18:29 ` Eli Zaretskii
2008-12-24 18:55 ` Stefan Monnier
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-24 18:29 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, emacs-devel, Roland.Winkler
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de, lekktu@gmail.com, emacs-devel@gnu.org
> Date: Wed, 24 Dec 2008 11:47:12 -0500
>
> >> > It's not hypothetical, I've seen such cases and reported them to
> >> > Roland.
> >> What were those cases?
> > Processes that disappeared while Emacs was reading /proc, for example.
>
> Then don't return them at all
How? I don't know enough about Linux kernel internals to decide which
attribute's absence means that the process died while Emacs was
reading /proc. For examples, quite a few lack the command line, but I
don't think that's a good reason to not return such processes. In
addition, judging by comments in procps sources, the set of attributes
depend on the version of the Linux kernel. If you (or someone else)
can define a clear logic, one that won't change with the next release
of the kernel, then perhaps we could avoid returning such processes.
Reading /proc is inherently prone to race conditions with the kernel,
unless someone can suggest a way of getting from /proc a consistent
snapshot of the set of system processes. I don't see how to overcome
this difficulty at the primitive level.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-24 18:29 ` Eli Zaretskii
@ 2008-12-24 18:55 ` Stefan Monnier
2008-12-24 21:12 ` Eli Zaretskii
0 siblings, 1 reply; 53+ messages in thread
From: Stefan Monnier @ 2008-12-24 18:55 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland.Winkler
>> > Processes that disappeared while Emacs was reading /proc, for example.
>> Then don't return them at all
> How? I don't know enough about Linux kernel internals to decide which
> attribute's absence means that the process died while Emacs was
> reading /proc.
AFAIK we're talking about ppid, and this info is always present, so if
it's absent, don't return the process.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-24 18:55 ` Stefan Monnier
@ 2008-12-24 21:12 ` Eli Zaretskii
2008-12-30 17:11 ` Stefan Monnier
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-24 21:12 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, emacs-devel, Roland.Winkler
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de, lekktu@gmail.com, emacs-devel@gnu.org
> Date: Wed, 24 Dec 2008 13:55:51 -0500
>
> >> > Processes that disappeared while Emacs was reading /proc, for example.
> >> Then don't return them at all
> > How? I don't know enough about Linux kernel internals to decide which
> > attribute's absence means that the process died while Emacs was
> > reading /proc.
>
> AFAIK we're talking about ppid, and this info is always present, so if
> it's absent, don't return the process.
Can you find any authoritative reference that says we can rely on
this? I couldn't even find a decent documentation of /proc when I was
working on these primitives, let alone some information about what
attributes are always present or how that changes with the kernel
version.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-24 21:12 ` Eli Zaretskii
@ 2008-12-30 17:11 ` Stefan Monnier
2008-12-30 22:02 ` Eli Zaretskii
0 siblings, 1 reply; 53+ messages in thread
From: Stefan Monnier @ 2008-12-30 17:11 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland.Winkler
>> >> > Processes that disappeared while Emacs was reading /proc, for example.
>> >> Then don't return them at all
>> > How? I don't know enough about Linux kernel internals to decide which
>> > attribute's absence means that the process died while Emacs was
>> > reading /proc.
>>
>> AFAIK we're talking about ppid, and this info is always present, so if
>> it's absent, don't return the process.
> Can you find any authoritative reference that says we can rely on
> this? I couldn't even find a decent documentation of /proc when I was
> working on these primitives, let alone some information about what
> attributes are always present or how that changes with the kernel
> version.
The ppid is in the /proc/NNN/stat file, those attributes are
distinguished by their order, so if it's missing the ordering gets
messed up, so it can't be missing. As for the /proc/NNN/stat file
missing, that would mean that pretty much all the attributes returned by
`ps' would be missing, so we can definitely count on its presence.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-30 17:11 ` Stefan Monnier
@ 2008-12-30 22:02 ` Eli Zaretskii
2008-12-31 1:40 ` Stefan Monnier
0 siblings, 1 reply; 53+ messages in thread
From: Eli Zaretskii @ 2008-12-30 22:02 UTC (permalink / raw
To: Stefan Monnier; +Cc: lekktu, emacs-devel, Roland.Winkler
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de, lekktu@gmail.com, emacs-devel@gnu.org
> Date: Tue, 30 Dec 2008 12:11:15 -0500
>
> >> AFAIK we're talking about ppid, and this info is always present, so if
> >> it's absent, don't return the process.
>
> > Can you find any authoritative reference that says we can rely on
> > this? I couldn't even find a decent documentation of /proc when I was
> > working on these primitives, let alone some information about what
> > attributes are always present or how that changes with the kernel
> > version.
>
> The ppid is in the /proc/NNN/stat file, those attributes are
> distinguished by their order, so if it's missing the ordering gets
> messed up, so it can't be missing. As for the /proc/NNN/stat file
> missing, that would mean that pretty much all the attributes returned by
> `ps' would be missing, so we can definitely count on its presence.
Sorry, this doesn't even come close to being an "authoritative
reference". These are just deliberations based on some concept of how
/proc is implemented in the Linux kernel, and I have no idea how close
is this concept to the truth.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: proced: ppid of process ID 0 can be 0
2008-12-30 22:02 ` Eli Zaretskii
@ 2008-12-31 1:40 ` Stefan Monnier
0 siblings, 0 replies; 53+ messages in thread
From: Stefan Monnier @ 2008-12-31 1:40 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel, Roland.Winkler
> Sorry, this doesn't even come close to being an "authoritative
> reference". These are just deliberations based on some concept of how
> /proc is implemented in the Linux kernel, and I have no idea how close
> is this concept to the truth.
No, this is not based on any details of how it's implemented in
the kernel. It's based on how the info is provided to the user
processes. I'm pretty sure if you look at it, you'll come to the
same conclusion.
Stefan
^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2008-12-31 1:40 UTC | newest]
Thread overview: 53+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-20 2:52 proced: ppid of process ID 0 can be 0 Juanma Barranquero
2008-12-20 3:27 ` Stefan Monnier
2008-12-20 4:31 ` Chong Yidong
2008-12-20 19:10 ` Stefan Monnier
2008-12-20 10:20 ` Juanma Barranquero
2008-12-20 11:34 ` Eli Zaretskii
2008-12-20 19:41 ` Roland Winkler
2008-12-20 21:02 ` Juanma Barranquero
2008-12-20 22:02 ` Eli Zaretskii
2008-12-20 22:41 ` Roland Winkler
2008-12-21 4:15 ` Eli Zaretskii
2008-12-21 4:48 ` Roland Winkler
2008-12-21 19:17 ` Eli Zaretskii
2008-12-21 21:26 ` Juanma Barranquero
2008-12-22 4:09 ` Eli Zaretskii
2008-12-22 10:41 ` Juanma Barranquero
2008-12-22 19:17 ` Eli Zaretskii
2008-12-22 19:26 ` Juanma Barranquero
2008-12-22 2:45 ` Stefan Monnier
2008-12-22 4:08 ` Eli Zaretskii
2008-12-22 4:17 ` Miles Bader
2008-12-22 19:10 ` Eli Zaretskii
2008-12-22 8:54 ` Harald Hanche-Olsen
2008-12-22 10:43 ` Juanma Barranquero
2008-12-22 10:50 ` Harald Hanche-Olsen
2008-12-22 18:03 ` Giorgos Keramidas
2008-12-22 10:59 ` Andreas Schwab
2008-12-22 19:22 ` Eli Zaretskii
2008-12-22 19:37 ` David De La Harpe Golden
2008-12-22 19:59 ` Andreas Schwab
2008-12-22 12:23 ` Stefan Monnier
2008-12-22 19:57 ` Eli Zaretskii
2008-12-22 22:24 ` Stefan Monnier
2008-12-23 4:02 ` Eli Zaretskii
2008-12-23 12:28 ` Roland Winkler
2008-12-23 14:44 ` Stefan Monnier
2008-12-23 19:12 ` Eli Zaretskii
2008-12-23 20:41 ` Stefan Monnier
2008-12-23 22:34 ` Giorgos Keramidas
2008-12-24 2:34 ` Stefan Monnier
2008-12-24 4:14 ` Eli Zaretskii
2008-12-24 16:47 ` Stefan Monnier
2008-12-24 4:15 ` Eli Zaretskii
2008-12-24 16:47 ` Stefan Monnier
2008-12-24 18:29 ` Eli Zaretskii
2008-12-24 18:55 ` Stefan Monnier
2008-12-24 21:12 ` Eli Zaretskii
2008-12-30 17:11 ` Stefan Monnier
2008-12-30 22:02 ` Eli Zaretskii
2008-12-31 1:40 ` Stefan Monnier
2008-12-22 8:28 ` Ulrich Mueller
2008-12-21 2:18 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2008-12-24 7:42 grischka
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.