From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: grep-use-null-device Date: Thu, 01 Sep 2005 18:16:08 +0200 Message-ID: <85slwovk53.fsf@lola.goethe.zz> References: <87ll2kiczv.fsf@jurta.org> <878xyiyh2n.fsf-monnier+emacs@gnu.org> <87mzmy1wmh.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1125592231 23263 80.91.229.2 (1 Sep 2005 16:30:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 1 Sep 2005 16:30:31 +0000 (UTC) Cc: Juri Linkov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 01 18:30:28 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EAruF-0002tL-GD for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2005 18:27:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EAryU-0002vT-HD for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2005 12:31:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EAruv-0000lJ-SC for emacs-devel@gnu.org; Thu, 01 Sep 2005 12:27:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EArut-0000jI-9e for emacs-devel@gnu.org; Thu, 01 Sep 2005 12:27:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EArus-0000XD-ER for emacs-devel@gnu.org; Thu, 01 Sep 2005 12:27:54 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EArnf-00036I-Tf for emacs-devel@gnu.org; Thu, 01 Sep 2005 12:20:28 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1EArjp-0001OS-U6; Thu, 01 Sep 2005 12:16:30 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id C97D91C4CE15; Thu, 1 Sep 2005 18:16:08 +0200 (CEST) Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Thu, 01 Sep 2005 10:59:48 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:42560 Archived-At: Stefan Monnier writes: >>>> `compilation-start' needs to check if the process is running >>>> before calling `process-send-eof': >>> >>> That's odd. AFAICT no blobking operation takes place between the >>> start-process and the process-send-eof, so the process-status should still >>> be `run' no matter how quickly the process exits (because Emacs shouldn't >>> process the SIGCHLD it receives until later). >>> >>> What am I missing? > >> The process exits during execution of create_process. The gdb log below >> with a breakpoint on sigchld_handler demonstrates what really happens: > >> Breakpoint 4, sigchld_handler (signo=17) at process.c:6249 [...] > Oh, I now see that process-send-eof does: > > if (! NILP (XPROCESS (proc)->raw_status_low)) > update_status (XPROCESS (proc)); > > which basically copies the asynchronously updated proc->raw_status_* to the > synchronously updated proc->status. > > Since this process status can change asynchronously, adding your test > for (eq (process-status proc) 'run) before calling process-send-eof doesn't > fix the bug but just narrows the window of the race condition because the > status can still change between the call to process-status and the call to > process-send-eof. > > So I suggest the patch below instead, [...] > + (when compilation-disable-input > + (condition-case nil > + (process-send-eof proc) > + ;; The process may have exited already. > + (error nil))) > (setq compilation-in-progress > (cons proc compilation-in-progress))) > ;; No asynchronous processes available. I think it is the wrong fix to just ignore an error which should not occur in the first place. Rather process-send-eof should be fixed not to throw an error as long as the process is not considered dead from Emacs' point of view. That there is nobody to actually look at the eof can't be considered a problem in asynchronous operations: the consuming process can close down without waiting for an explicit eof. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum