X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <4EA1812B.4060503@cornell.edu> References: <4E9ED08B DOT 3080503 AT cornell DOT edu> <20111019144910 DOT GB16351 AT calimero DOT vinschen DOT de> <20111019162219 DOT GB1085 AT ednor DOT casa DOT cgf DOT cx> <4E9F09AE DOT 7090609 AT cornell DOT edu> <4E9F2FE1 DOT 7050003 AT cornell DOT edu> <4EA01079 DOT 5010303 AT cornell DOT edu> <20111021094428 DOT GA2979 AT calimero DOT vinschen DOT de> <4EA1812B DOT 4060503 AT cornell DOT edu> Date: Fri, 21 Oct 2011 11:45:08 -0400 Message-ID: Subject: Re: Question about Cygwin's select() From: Jon Clugston To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id p9LFjaJB002157 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. Jon -- 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