Question about Cygwin's select()

Ken Brown kbrown@cornell.edu
Fri Oct 21 20:03:00 GMT 2011


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



More information about the Cygwin mailing list