Mail Archives: cygwin/2011/10/21/16:03:58
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
- Raw text -