From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: proced: ppid of process ID 0 can be 0 Date: Sun, 21 Dec 2008 21:17:26 +0200 Message-ID: References: <18765.19040.568030.246241@tfkp04.physik.uni-erlangen.de> <18765.29820.997276.703222@tfkp04.physik.uni-erlangen.de> <18765.51840.943986.608296@tfkp04.physik.uni-erlangen.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1229887060 6034 80.91.229.12 (21 Dec 2008 19:17:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Dec 2008 19:17:40 +0000 (UTC) Cc: lekktu@gmail.com, emacs-devel@gnu.org To: Roland Winkler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 21 20:18:46 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LETp7-0008H5-G3 for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2008 20:18:46 +0100 Original-Received: from localhost ([127.0.0.1]:55087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LETnu-0002zN-Kx for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2008 14:17:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LETnp-0002zG-JS for emacs-devel@gnu.org; Sun, 21 Dec 2008 14:17:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LETno-0002yy-D5 for emacs-devel@gnu.org; Sun, 21 Dec 2008 14:17:25 -0500 Original-Received: from [199.232.76.173] (port=51896 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LETno-0002yv-6B for emacs-devel@gnu.org; Sun, 21 Dec 2008 14:17:24 -0500 Original-Received: from mtaout7.012.net.il ([84.95.2.19]:19409) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LETnn-0007G5-Pa for emacs-devel@gnu.org; Sun, 21 Dec 2008 14:17:24 -0500 Original-Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KC800G00QZ9EF00@i-mtaout7.012.net.il> for emacs-devel@gnu.org; Sun, 21 Dec 2008 21:19:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.252.83]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KC800FYJR12YV50@i-mtaout7.012.net.il>; Sun, 21 Dec 2008 21:19:51 +0200 (IST) In-reply-to: <18765.51840.943986.608296@tfkp04.physik.uni-erlangen.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:107162 Archived-At: > Date: Sun, 21 Dec 2008 05:48:00 +0100 > From: "Roland Winkler" > 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.