From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: delete-process bug Date: Thu, 25 May 2006 10:55:08 -0400 Message-ID: References: <87k69eyddj.fsf@lrde.org> <87fyj0r41g.fsf@lrde.org> <20060524112846.GA12046@agmartin.aq.upm.es> <87bqtmjrsh.fsf_-_@lrde.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1148568931 11834 80.91.229.2 (25 May 2006 14:55:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 25 May 2006 14:55:31 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 25 16:55:29 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FjHFH-0004U6-6r for ged-emacs-devel@m.gmane.org; Thu, 25 May 2006 16:55:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FjHFG-0000zO-PW for ged-emacs-devel@m.gmane.org; Thu, 25 May 2006 10:55:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FjHF7-0000xj-2e for emacs-devel@gnu.org; Thu, 25 May 2006 10:55:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FjHF6-0000wy-KE for emacs-devel@gnu.org; Thu, 25 May 2006 10:55:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FjHF6-0000wv-H3 for emacs-devel@gnu.org; Thu, 25 May 2006 10:55:16 -0400 Original-Received: from [209.226.175.93] (helo=tomts36-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FjHJm-0000bO-Lo for emacs-devel@gnu.org; Thu, 25 May 2006 11:00:07 -0400 Original-Received: from localhost ([70.53.193.49]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060525145514.VPKQ13653.tomts36-srv.bellnexxia.net@localhost>; Thu, 25 May 2006 10:55:14 -0400 Original-Received: by localhost (Postfix, from userid 20848) id CD1EB8258; Thu, 25 May 2006 10:55:08 -0400 (EDT) Original-To: michael.cadilhac@lrde.org (=?iso-8859-1?Q?Micha=EBl?= Cadilhac) In-Reply-To: <87bqtmjrsh.fsf_-_@lrde.org> (=?iso-8859-1?Q?Micha=EBl?= Cadilhac's message of "Thu, 25 May 2006 12:57:18 +0200") 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:55279 Archived-At: > This is not really due to my patch. However, it shows a real race > condition in process management of Emacs: [...] > After an hour of debugging, I can propose a small change that fixes > this bug and lets no room for any other race condition of that kind, > AFAICT. [...] > + * process.c (Fdelete_process): Wait for process termination to > + avoid `sigchld_handler' to consider the process to be synchronous. I don't think it's a good idea. The process might not die in response to delete-process, so we would end up waiting "indefinitely". I think in order to avoid such race-conditions without waiting for the process's death, we'll need to remember those processes that were deleted but aren't dead yet. Of course, it goes against the docstring of `delete-process' which says "forget about it immediately". But we don't need to keep the whole process around; just the PID should be enough, kept in a list of "deleted but not dead" PIDs. See sample patch below. Stefan --- process.c 12 mai 2006 11:54:58 -0400 1.481 +++ process.c 25 mai 2006 10:51:51 -0400 @@ -778,6 +778,13 @@ return proc; } +/* Fdelete_process promises to immediately forget about the process, but in + reality Emacs needs to remember those processes until they die, otherwise + it doesn't know what to do with the SIGCHLD signal and might be tempted + to interpret that signal as applying to some other non-deleted + process ;-(. */ +static Lisp_Object live_deleted_processes; + DEFUN ("delete-process", Fdelete_process, Sdelete_process, 1, 1, 0, doc: /* Delete PROCESS: kill it and forget about it immediately. PROCESS may be a process, a buffer, the name of a process or buffer, or @@ -800,6 +807,9 @@ else if (XINT (p->infd) >= 0) { Fkill_process (process, Qnil); + live_deleted_processes = Fcons (make_number (p->pid), + /* GC previous elements. */ + Fdelq (Qnil, live_deleted_processes)); /* Do this now, since remove_process will make sigchld_handler do nothing. */ p->status = Fcons (Qsignal, Fcons (make_number (SIGKILL), Qnil)); @@ -6373,6 +6383,13 @@ /* Find the process that signaled us, and record its status. */ + /* Maybe the process was already passed to Fdelete_process. */ + tail = Fmemq (make_number (pid), live_deleted_processes); + if (!NILP (tail)) { + Fsetcar (tail, Qnil); + return; + } + p = 0; for (tail = Vprocess_alist; GC_CONSP (tail); tail = XCDR (tail)) { @@ -7357,6 +7374,7 @@ void init_process () { + live_deleted_processes = Qnil; } void