X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.3 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_NEUTRAL
X-Spam-Check-By: sourceware.org
Message-ID: <4E9F89BF.4090401@cornell.edu>
Date: Wed, 19 Oct 2011 22:38:55 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Question about Cygwin's select()
References: <4E9ED08B DOT 3080503 AT cornell DOT edu>	<20111019144910 DOT GB16351 AT calimero DOT vinschen DOT de>	<20111019162219 DOT GB1085 AT ednor DOT casa DOT cgf DOT cx>	<4E9F09AE DOT 7090609 AT cornell DOT edu>	<4E9F2FE1 DOT 7050003 AT cornell DOT edu> <CAG_2cT=n-a0ay0WOwv181nUHG9UAN=uW+CGpza9P15ZEGQGnnQ AT mail DOT gmail DOT com>
In-Reply-To: <CAG_2cT=n-a0ay0WOwv181nUHG9UAN=uW+CGpza9P15ZEGQGnnQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 10/19/2011 4:30 PM, Jon Clugston wrote:
> On Wed, Oct 19, 2011 at 4:15 PM, Ken Brown<kbrown AT cornell DOT 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