From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: dhruva Newsgroups: gmane.emacs.devel Subject: Re: [andrew.maguire@ge.com: Emacs 22.1 hung after delete-process] Date: Fri, 17 Aug 2007 10:57:58 +0530 Message-ID: References: <46C404AD.8040908@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1187328491 31424 80.91.229.12 (17 Aug 2007 05:28:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Aug 2007 05:28:11 +0000 (UTC) Cc: rgm@gnu.org, emacs-devel@gnu.org, jasonr@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 17 07:28:09 2007 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 1ILuNV-0000SP-2A for ged-emacs-devel@m.gmane.org; Fri, 17 Aug 2007 07:28:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ILuNU-0006zp-1j for ged-emacs-devel@m.gmane.org; Fri, 17 Aug 2007 01:28:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ILuNO-0006za-T4 for emacs-devel@gnu.org; Fri, 17 Aug 2007 01:28:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ILuNO-0006zG-0e for emacs-devel@gnu.org; Fri, 17 Aug 2007 01:28:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ILuNN-0006zD-Ot for emacs-devel@gnu.org; Fri, 17 Aug 2007 01:28:01 -0400 Original-Received: from mu-out-0910.google.com ([209.85.134.189]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ILuNN-0006EN-1m for emacs-devel@gnu.org; Fri, 17 Aug 2007 01:28:01 -0400 Original-Received: by mu-out-0910.google.com with SMTP id g7so465991muf for ; Thu, 16 Aug 2007 22:27:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oZxbZJBA8bnIVkqtGvtsXT6+LERWUZQUHADB7jb86+djblo39qkbsu0q17h7NccOTQRbW9vA8w/0di7ZTWlbiVZYac9rOG9/Drzn9/g878Z4HhPhb1NvPlbaCs1AXbamR/GVljdF2oVrzlFTtv7iI/YGF4dQTqYrvFQRqBXr+f4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iBvu1jhThZioyKzhAWCO6XVIXiR2M4Ao22+Wz/0zPMXJw/L1c7sWov97P1AznC+mBGm3MTtw/7XAsy29NC4XqgCx/wH1F4hgx/YTU2QN9fTwxfQzwW5a3iuISuQVAGtydrOl4G7OCq5TFGPSp4c7rksQ6zxKU5K64LNqpo6swNk= Original-Received: by 10.78.132.2 with SMTP id f2mr891391hud.1187328478726; Thu, 16 Aug 2007 22:27:58 -0700 (PDT) Original-Received: by 10.78.206.20 with HTTP; Thu, 16 Aug 2007 22:27:58 -0700 (PDT) In-Reply-To: Content-Disposition: inline X-Detected-Kernel: Linux 2.6 (newer, 2) 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:76672 Archived-At: Hi, On 8/17/07, Richard Stallman wrote: > I have put it a fix that seems to solve this problem (observed on my > box). > > Thanks for working on this. In a few days, when you find out whether > the fix really works right, please tell me by responding to this message. My usage of Emacs with lot of subprocesses is highly limited (but I am creating such scenarios and testing), I therefore request a wider testing. For anyone willing to try a new patch, I am posting it here. The rationale for reverting the changes done in my earlier patch is as follows. Since I am a novice in contributing patches, I request fellow developers guide me (as you have all been doing): 1. In the delete_child, I had increased the wait's timeout from 1000ms to INFINITE. Since this gets called in the main thread, it is not a good idea to wait infinitely on a kernel object. 2. If something goes wrong in the thread on which the main thread waits, it will result in a deadlock and the process hangs The new changes: 1. The new process (perl.exe in this example) is created in a new thread and the thread entry function is reader_thread 2. The blocking calls in this new thread which handles the IO from the sub process is through a call to _sys_read_ahead. This behaves like a select by reading a single byte. 3. The _read call is synchronous and non-interruptible. 4. Hence, to make that function return when we want to shut down a process, I close the pipe on which the read is happening from the main thread. The call to _read returns with failure. 5. I am using PulseEvent instead of SetEvent as the former ensures releasing of threads waiting on that event. This could bring the much required delay before the main thread waits for the other thread's termination. 6. An additional Sleep is called to relinquish the CPU quanta so that a different thread could get scheduled. There is a higher probability of the thread waiting on the event (which the main thread has signaled) getting scheduled before the main thread gets the next time slice (based on what little I know of the windows scheduler). 7. If all fails, we do not wait infinitely (as was in my previous patch). diff -r 8ea8d2856c72 src/w32proc.c --- a/src/w32proc.c Thu Aug 16 20:46:34 2007 +0000 +++ b/src/w32proc.c Fri Aug 17 10:43:58 2007 +0530 @@ -215,7 +215,13 @@ delete_child (child_process *cp) { /* let the thread exit cleanly if possible */ cp->status = STATUS_READ_ERROR; - SetEvent (cp->char_consumed); + /* Close the pipe so that the blocking _sys_read_ahead fails + and returns */ + close (cp->fd); + /* Ensure the waiting threads are released before proceeding */ + PulseEvent (cp->char_consumed); + /* Give the other thread an opportunity to exit gracefully */ + Sleep (0); if (WaitForSingleObject (cp->thrd, 1000) != WAIT_OBJECT_0) { DebPrint (("delete_child.WaitForSingleObject (thread) failed " -dky -- Dhruva Krishnamurthy Contents reflect my personal views only!