From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32534 invoked by alias); 21 Oct 2011 20:03:50 -0000 Received: (qmail 32362 invoked by uid 22791); 21 Oct 2011 20:03:49 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_NEUTRAL X-Spam-Check-By: sourceware.org Received: from granite1.mail.cornell.edu (HELO authusersmtp.mail.cornell.edu) (128.253.83.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Oct 2011 20:03:34 +0000 Received: from [128.84.234.240] (dhcp240.math.cornell.edu [128.84.234.240]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id p9LK3Wdu016632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 21 Oct 2011 16:03:33 -0400 (EDT) Message-ID: <4EA1D016.5050605@cornell.edu> Date: Fri, 21 Oct 2011 20:03:00 -0000 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Question about Cygwin's select() References: <4E9ED08B.3080503@cornell.edu> <20111019144910.GB16351@calimero.vinschen.de> <20111019162219.GB1085@ednor.casa.cgf.cx> <4E9F09AE.7090609@cornell.edu> <4E9F2FE1.7050003@cornell.edu> <4EA01079.5010303@cornell.edu> <20111021094428.GA2979@calimero.vinschen.de> <4EA1812B.4060503@cornell.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-10/txt/msg00436.txt.bz2 On 10/21/2011 11:45 AM, Jon Clugston wrote: > On Fri, Oct 21, 2011 at 10:26 AM, Ken Brown wrote: >> On 10/21/2011 5:44 AM, Corinna Vinschen wrote: >>> >>> On Oct 20 08:13, Ken Brown wrote: >>>> >>>> On 10/19/2011 4:15 PM, Ken Brown wrote: >>>>> >>>>> I don't have a testcase yet, but I have a clearer idea of what's >>>>> happening. It actually has nothing to do with the gdb subprocess, but >>>>> rather is a problem that can occur whenever emacs is running its main >>>>> command loop. emacs polls for keyboard input while also using select to >>>>> check for output from subprocesses. It's in this setting that select >>>>> often fails with EINTR, even when there are no subprocesses running. I >>>>> wonder if the keyboard polling is doing something that interrupts the >>>>> select call. >>>> >>>> I think this guess is correct. If I start up emacs and do nothing, >>>> strace shows many sequences like the following: >>>> >>>> - emacs calls select >>>> - a timer sends SIGALRM >>>> - select returns -1 with error EINTR >>>> >>>> The EINTR isn't actually visible in the strace output, but I do see >>>> "select_stuff::wait: signal received". A glance at select.cc >>>> indicates that this is the debug output produced by select when it >>>> is about to return -1 with EINTR. >>>> >>>> These sequences always occur in connection with start_thread_socket. >>>> I've appended a typical excerpt from the strace output below. >>>> Please let me know if you need to see more strace output. I didn't >>>> want to spam the list by sending too much. >>>> >>>> You still might need more information, but I can at least refine my >>>> original question: Is it reasonable that select should give up and >>>> return -1 because a timer has sent SIGALRM? >>> >>> If SIGALRM isn't blocked, then, yes. What is setting up the timer? >> >> Emacs sets up the timer. But I just looked at the code in which emacs calls >> select, and it looks like it reduces the select timeout to make sure that >> select will return before the next SIGALRM is expected. I don't know why >> that's not working. > > There is absolutely no guarantee that you can do that. If the process > is put to sleep between the computation of the select timeout and the > actual call to "select", this logic fails. If the code assumes that > it can reliably cause "select" to time out before a pending alarm > expires, then it is broken. You're right. Blocking SIGALRM before the call to select (in the situation where the timeout was reduced) seems to fix the problem. I still have to do some more testing, but so far it looks good. Thanks. 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