[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9767: 24.0.90; gdb initialization on Cygwin

From: Ken Brown
Subject: bug#9767: 24.0.90; gdb initialization on Cygwin
Date: Wed, 19 Oct 2011 16:43:06 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

On 10/19/2011 4:26 PM, Eli Zaretskii wrote:
Date: Wed, 19 Oct 2011 16:00:09 -0400
From: Ken Brown<address@hidden>
CC: address@hidden

After M-x gdb finishes its initialization, emacs goes into its command
loop.  read_char calls sit_for with a timeout of 30 seconds, and sit_for
calls wait_reading_process_output, which calls select.  The call to
select fails immediately with EINTR.  I don't understand the command
loop well enough to know what's interrupting the select call.

EINTR means that some signal arrived (assuming that Cygwin's `select'
is Posix-ish enough).  The question is, which signal?  Does Cygwin
provide any tools to see which signals were delivered to a program?

There's a program called strace that produces lots of debugging information like this. I'll give it a try.

Also, the fact that `select' is interrupted doesn't necessarily mean
that the input arrival is ignored, does it?  Doesn't
wait_reading_process_output loop around and examines the input
descriptors again?  If not, why not?  IOW, why should EINTR become a

No, wait_reading_process_output treats EINTR as though it meant there's no input available. Here's the relevant code from process.c, line 4638.

      if (nfds < 0)
          if (xerrno == EINTR)
            no_avail = 1;

Even worse, xg_select (which is what the Cygwin build uses) deliberately returns -1 and sets errno = EINTR whenever the actual select call returns 0. Here's the code from xg_select.c, line 141:

      /* To not have to recalculate timeout, return like this.  */
      if (retval == 0)
          retval = -1;
          errno = EINTR;

I don't know the rationale for treating EINTR the same as no input available, but I agree that it doesn't seem right.

The code in keyboard.c is full of alarms and timers, presumably related
to polling for keyboard input.  Could this polling be doing something
that interrupts the select call under some circumstances?

Atimers (those which are responsible for the "busy cursor" display)
could deliver SIGALRM, yes.  But again, I don't see why this should
fail the loop that waits for input, and then only in this particular
case.  Something else is at work here.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]