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 06:15:10 +0200 Message-ID: References: <18765.19040.568030.246241@tfkp04.physik.uni-erlangen.de> <18765.29820.997276.703222@tfkp04.physik.uni-erlangen.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1229832923 14513 80.91.229.12 (21 Dec 2008 04:15:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Dec 2008 04:15:23 +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 05:16:30 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 1LEFjw-0002Tb-Kz for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2008 05:16:28 +0100 Original-Received: from localhost ([127.0.0.1]:43294 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LEFik-0006Rh-2o for ged-emacs-devel@m.gmane.org; Sat, 20 Dec 2008 23:15:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LEFif-0006RS-PQ for emacs-devel@gnu.org; Sat, 20 Dec 2008 23:15:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LEFie-0006RG-8c for emacs-devel@gnu.org; Sat, 20 Dec 2008 23:15:08 -0500 Original-Received: from [199.232.76.173] (port=45299 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LEFie-0006RD-3Q for emacs-devel@gnu.org; Sat, 20 Dec 2008 23:15:08 -0500 Original-Received: from mtaout2.012.net.il ([84.95.2.4]:41811) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LEFid-0007Ie-HT for emacs-devel@gnu.org; Sat, 20 Dec 2008 23:15:08 -0500 Original-Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KC700200L00Y500@i_mtaout2.012.net.il> for emacs-devel@gnu.org; Sun, 21 Dec 2008 06:17:35 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.252.83]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KC700EBNL9A2O20@i_mtaout2.012.net.il>; Sun, 21 Dec 2008 06:17:35 +0200 (IST) In-reply-to: <18765.29820.997276.703222@tfkp04.physik.uni-erlangen.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 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:107152 Archived-At: > Date: Sat, 20 Dec 2008 23:41:00 +0100 > From: "Roland Winkler" > 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.