Question about Cygwin's select()

[Ken Brown]

On 10/19/2011 4:30 PM, Jon Clugston wrote:
> On Wed, Oct 19, 2011 at 4:15 PM, Ken Brown<kbrown@cornell.edu>  wrote:
>> On 10/19/2011 1:32 PM, Ken Brown wrote:
>>>
>>> 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.
>>
>> 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.
>>
>> Unfortunately, the keyboard code (in src/keyboard.c) is full of alarms and
>> timers and other things I know nothing about, so it's not going to be easy
>> for me to come up with an STC.  I'll see if I can get help on the
>> emacs-devel list.
>>
>> Ken
>>
>
> Any code calling "select" (and many other kernel calls) must handle
> the case of the call returning EINTR for many (or no particular)
> reason(s).  If emacs is assuming certain calls under certain
> conditions will never return EINTR, then it is definitely not written
> robustly.

emacs does handle the EINTR.  Sorry if I suggested otherwise.  I was 
just surprised that I was getting that error so often, and I thought it 
was responsible for the gdb problem I was seeing.  I'll keep debugging.

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