Question about Cygwin's select()

Ken Brown kbrown@cornell.edu
Wed Oct 19 17:32:00 GMT 2011


On 10/19/2011 12:22 PM, Christopher Faylor wrote:
> On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote:
>> On Oct 19 09:28, Ken Brown wrote:
>>> I'm trying to debug an emacs problem, and I'm running into something
>>> I don't understand involving Cygwin's select.  I'll try to make an
>>> STC if necessary, but I thought I'd start with a verbal description
>>> in case there's an easy answer.  Here's the situation:
>>>
>>> emacs creates a subprocess running gdb and sends a bunch of commands
>>> to gdb without immediately reading the resulting output.  emacs then
>>> goes into a loop in which it waits for keyboard input and
>>> periodically calls select to check for output from subprocesses.
>>> The first call to select has a 30 second timeout and *always* fails
>>> with EINTR.  As a result, emacs doesn't read the output from gdb
>>> right away and doesn't properly initialize the gdb buffer.
>>> Subsequent calls to select sometimes succeed and sometimes fail.
>>> When I'm running emacs under gdb and stepping through it, the buffer
>>> eventually gets initialized.  When I'm running emacs outside of gdb,
>>> the buffer doesn't get initialized until I press Return.
>>>
>>> I have a simple workaround for this, but I'd like to be sure there
>>> isn't some underlying bug that I'm masking with the workaround.  So
>>> my question is this: Is there some reason that I should expect that
>>> first call to select to consistently fail with EINTR, or might this
>>> indicate a bug?
>>>
>>> I realize that it might not be possible to answer the question based
>>> on the information I've provided, but I thought it was worth a try.
>>
>> Some details are missing like the objects used to communicate with GDB.
>> Does Emacs use a pseudo tty or a pipe?  Is that with Cygwin from CVS or
>> with 1.7.9?  And what's your workaround?  The EINTR sounds weird.  A
>> testcase would be most helpful.
>
> It isn't clear if you're getting the EINTR by looking at strace output
> or from the code.  If it's strace then be aware that sometimes the
> output just reports the current errno regardless of whether there is an
> error or not.

I'm getting the EINTR by examining errno while running the program under 
gdb.  But thanks for the heads-up about strace.  I didn't know that.

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