Mail Archives: cygwin/2011/10/22/05:55:29
On 10/21/2011 4:03 PM, Ken Brown wrote:
> 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'm wrong. I've been focusing too much on the select interruption.
This is actually harmless and is correctly treated by emacs the same as
a select timeout. It doesn't explain or solve the original gdb problem.
Sorry for the noise.
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 -