From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10895 invoked by alias); 7 Aug 2014 18:54:11 -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 10803 invoked by uid 89); 7 Aug 2014 18:54:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: limerock03.mail.cornell.edu Received: from limerock03.mail.cornell.edu (HELO limerock03.mail.cornell.edu) (128.84.13.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Aug 2014 18:54:09 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock03.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s77Is7cW006798 for ; Thu, 7 Aug 2014 14:54:07 -0400 Received: from [192.168.1.4] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id s77Is6YK006789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 7 Aug 2014 14:54:07 -0400 Message-ID: <53E3CB46.1020909@cornell.edu> Date: Thu, 07 Aug 2014 18:54:00 -0000 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: (call-process ...) hangs in emacs References: <53DB8D23.7060806@alice.it> <20140801133225.GD25860@calimero.vinschen.de> <53DEDBBA.20102@cornell.edu> <20140804080034.GA2578@calimero.vinschen.de> <53DF8BDC.8090104@cornell.edu> <20140804134526.GK2578@calimero.vinschen.de> <53E0CC2D.4080305@cornell.edu> <20140805135830.GA9994@calimero.vinschen.de> <53E11A93.9070800@cornell.edu> <20140805184047.GC13601@calimero.vinschen.de> <53E3685B.8050508@cornell.edu> <53E39BAD.3010004@redhat.com> In-Reply-To: <53E39BAD.3010004@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00168.txt.bz2 On 8/7/2014 11:30 AM, Eric Blake wrote: > On 08/07/2014 05:51 AM, Ken Brown wrote: >> >> I think I found the problem with NORMAL mutexes. emacs calls >> pthread_atfork after initializing the mutexes, and the resulting >> 'prepare' handler locks the mutexes. (The parent and child handlers >> unlock them.) So when emacs calls fork, the mutexes are locked, and >> shortly thereafter the Cygwin DLL calls calloc, leading to a deadlock. >> Here's a gdb backtrace showing the sequence of calls: > > Arguably, that's an upstream bug in emacs. POSIX has declared > pthread_atfork to be fundamentally useless; it is broken by design, > because you cannot use it for anything that is not async-signal-safe > without risking deadlock. And (except for sem_post()), NONE of the > standardized locking functions are async-signal-safe. > > http://austingroupbugs.net/view.php?id=858 > > That said, it would still be nice to support this, since even though the > theory says it is broken, there are still lots of (broken) > programs/libraries still trying to use it. So what do you think emacs should do instead of using pthread_atfork? Or is it better to just remove it? I don't know how likely it is that this would cause a problem. Ken -- 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