From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Detecting a running process in Elisp Date: Sat, 27 Jul 2013 10:43:08 +0300 Message-ID: <83hafgzbw3.fsf@gnu.org> References: <87k3kd2r88.fsf@informatimago.com> <87bo5p2g58.fsf@informatimago.com> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1374911002 3949 80.91.229.3 (27 Jul 2013 07:43:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Jul 2013 07:43:22 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jul 27 09:43:23 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V2z9u-0000Jn-6I for geh-help-gnu-emacs@m.gmane.org; Sat, 27 Jul 2013 09:43:22 +0200 Original-Received: from localhost ([::1]:53435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2z9t-0004FB-DT for geh-help-gnu-emacs@m.gmane.org; Sat, 27 Jul 2013 03:43:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2z9j-0004Eh-0o for help-gnu-emacs@gnu.org; Sat, 27 Jul 2013 03:43:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2z9h-0000P8-Qa for help-gnu-emacs@gnu.org; Sat, 27 Jul 2013 03:43:10 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:63557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2z9h-0000OV-IT for help-gnu-emacs@gnu.org; Sat, 27 Jul 2013 03:43:09 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MQL00M003VG6G00@a-mtaout20.012.net.il> for help-gnu-emacs@gnu.org; Sat, 27 Jul 2013 10:43:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MQL00LB943VKKA0@a-mtaout20.012.net.il> for help-gnu-emacs@gnu.org; Sat, 27 Jul 2013 10:43:07 +0300 (IDT) In-reply-to: <87bo5p2g58.fsf@informatimago.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:92470 Archived-At: > From: "Pascal J. Bourguignon" > Date: Fri, 26 Jul 2013 22:57:39 +0200 > > Eli Zaretskii writes: > > >> From: "Pascal J. Bourguignon" > >> Date: Fri, 26 Jul 2013 18:58:15 +0200 > >> > >> > There's list-system-processes to list all of the processes, and > >> > process-attributes to examine their attributes, including name, > >> > command line, etc. > >> > >> And what is the function to lock the system so that the list of PIDs > >> returned by list-system-processes is consistent with the actual > >> processes in the system when you call process-attributes on them? > > > > How is this relevant to the OP's question? > > It is relevant to the answer, to the proposed API. Fair enough, then please explain what problem(s) you have in mind. If you are thinking about a process that was alive when list-system-processes was called, but is no longer there when process-attributes is called for its PID, the process-attributes is already immune to that: it will return nil. In general, any method that walks the list of the processes, querying the OS about each one, is prone to the same issues. The only way to avoid that is to have a system call that will produce a single coherent snapshot of the processes, together with every one of their attributes you will ever want to know about. If the OS doesn't provide such a system call, there's nothing an application can do better than cope with processes that disappear during the walk. And, FWIW, "ps -A" does not "lock" the system, either, so it suffers from the same issues. In practical terms, such "disappearing" processes are not a concern, since they are not different from a process that exited just before you called list-system-processes. Unless you want to write an OS monitor in Emacs Lisp, this shouldn't bother you.