X-Recipient: archive-cygwin AT delorie DOT com
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
Message-ID: <4EA1D016.5050605@cornell.edu>
Date: Fri, 21 Oct 2011 16:03:34 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
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 AT cygwin DOT com
Subject: Re: Question about Cygwin's select()
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> <CAG_2cTmQnJN-WpGv3RRFtq-zOkbWgLmDrSyzEzdEd4=Tf1dnKw AT mail DOT gmail DOT com>
In-Reply-To: <CAG_2cTmQnJN-WpGv3RRFtq-zOkbWgLmDrSyzEzdEd4=Tf1dnKw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 10/21/2011 11:45 AM, Jon Clugston wrote:
> On Fri, Oct 21, 2011 at 10:26 AM, Ken Brown<kbrown AT cornell DOT edu>  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