From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Mauger Newsgroups: gmane.emacs.devel Subject: Re: delete-process bug Date: Fri, 26 May 2006 17:27:36 +0000 (UTC) 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 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1148664527 348 80.91.229.2 (26 May 2006 17:28:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 26 May 2006 17:28:47 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 26 19:28:46 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 1Fjg6z-0007RN-Os for ged-emacs-devel@m.gmane.org; Fri, 26 May 2006 19:28:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fjg6z-0003R5-AT for ged-emacs-devel@m.gmane.org; Fri, 26 May 2006 13:28:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fjg6n-0003R0-Ra for emacs-devel@gnu.org; Fri, 26 May 2006 13:28:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fjg6m-0003Qg-Er for emacs-devel@gnu.org; Fri, 26 May 2006 13:28:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fjg6m-0003Qd-8D for emacs-devel@gnu.org; Fri, 26 May 2006 13:28:20 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FjgBh-0006lM-Ke for emacs-devel@gnu.org; Fri, 26 May 2006 13:33:26 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fjg6P-0007M6-PN for emacs-devel@gnu.org; Fri, 26 May 2006 19:27:58 +0200 Original-Received: from na6mk2fw02.fidelity.com ([192.223.243.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 May 2006 19:27:57 +0200 Original-Received: from mmaug by na6mk2fw02.fidelity.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 May 2006 19:27:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 33 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 192.223.243.6 (Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; JFV; IE 6.0 SP1 (FID r3.0); .NET CLR 1.0.3705; .NET CLR 1.1.4322)) 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:55333 Archived-At: Stefan Monnier iro.umontreal.ca> writes: > > > Thanks for working on this. I agree that `live_deleted_processes' > > is a good name. ("Zombie process" has a different meaning.) > > > However, maybe there is still a race condition. Suppose the signal > > comes in the middle of the line > > > + live_deleted_processes = Fcons (make_number (p->pid), > > + /* GC previous elements. */ > > + Fdelq (Qnil, live_deleted_processes)); > > > Suppose it comes between there and the call to remove_process? > > I think it's OK: if the signal handler comes before the assignment to > live_deleted_processes, then it'll all behave as if the signal came even > before the call to delete-process. If it comes afterwards, the signal will > be ignored (as if it came after the call to delete-process). > > > Does the right thing happen in all these cases? > > I believe so. > My instinct would be to add the pid to the list prior to causing the event that the list is designed to detect. Treating the signal as though it happened before the call to delete-process (if we don't add the pid to the list first) when we know it was most likely caused by delete-process seems to be asking for trouble. Just sayin'...