From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5880 invoked by alias); 15 Nov 2013 19:21:51 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 5863 invoked by uid 89); 15 Nov 2013 19:21:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mho-02-ewr.mailhop.org Received: from Unknown (HELO mho-02-ewr.mailhop.org) (204.13.248.72) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 15 Nov 2013 19:21:47 +0000 Received: from pool-98-110-183-69.bstnma.fios.verizon.net ([98.110.183.69] helo=cgf.cx) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1VhOxX-0008Qz-Rl for cygwin@cygwin.com; Fri, 15 Nov 2013 19:21:39 +0000 Received: from cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id E211460103 for ; Fri, 15 Nov 2013 14:21:38 -0500 (EST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19wsJ4Dzdb2e4WN6BrMuHVz Date: Fri, 15 Nov 2013 19:21:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: Intermittent failures retrieving process exit codes Message-ID: <20131115192138.GA6128@ednor.casa.cgf.cx> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <50C2498C.2000003@coverity.com> <50C276AC.9090301@mailme.ath.cx> <50D401EF.9040705@coverity.com> <52844B2E.5050902@coverity.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-11/txt/msg00278.txt.bz2 On Fri, Nov 15, 2013 at 07:53:26PM +0100, Denis Excoffier wrote: >On 2013-11-14 05:01, Tom Honermann wrote: >> On 12/21/2012 01:30 AM, Tom Honermann wrote: >>> >>> The workaround I implemented within Cygwin was simple and sloppy. I >>> added a call to Sleep(1000) immediately before the call to ExitThread() >>> in wait_sig() in winsup/cygwin/sigproc.cc. Since this thread (probably) >>> doesn't exit until the process is exiting anyway, the call to Sleep() >>> does not adversely affect shutdown. The thread just gets terminated >>> while in the call to Sleep() instead of exiting before the process is >>> terminated or getting terminated while still in the call to >>> ExitThread(). A better solution might be to avoid the thread exiting at >>> all (so long as it can't get terminated while holding critical >>> resources), or to have the process exiting thread wait on it. Neither >>> of these is ideal. Orderly shutdown of multi-threaded processes is >>> really hard to do correctly on Windows. > >I experience on Windows 7 (not on XP) some problems that may be related. >I would like to test your workaround, but sigproc.cc has much changed since >then, there is now an exit_thead function with the comment "Exit the current >thread very carefully.". I tried to insert Sleep(1000) at the end of >exit_thread, immediately before "ExitThread (0)", but this yielded no >change at all. > >Could someone be kind enough to update the workaround for modern sigproc.cc? You apparently are misunderstanding the whole point of the changes to sigproc.cc. They were to work around this very problem. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple