GNU bug report logs - #9767
24.0.90; gdb initialization on Cygwin

Previous Next

Full log

Message #17 received at 9767 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 9767 <at> debbugs.gnu.org
Subject: Re: bug#9767: 24.0.90; gdb initialization on Cygwin
Date: Wed, 19 Oct 2011 22:26:32 +0200

> Date: Wed, 19 Oct 2011 16:00:09 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: 9767 <at> debbugs.gnu.org
> 
> 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?

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
failure?

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.