X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.6 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_NEUTRAL
X-Spam-Check-By: sourceware.org
Message-ID: <4E9F09AE.7090609@cornell.edu>
Date: Wed, 19 Oct 2011 13:32:30 -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>
In-Reply-To: <20111019162219.GB1085@ednor.casa.cgf.cx>
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 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