From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: Question about Cygwin's select()
Date: Wed, 19 Oct 2011 15:29:00 -0000 [thread overview]
Message-ID: <4E9EECDB.8020005@cornell.edu> (raw)
In-Reply-To: <20111019144910.GB16351@calimero.vinschen.de>
On 10/19/2011 10:49 AM, 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.
Sorry for the missing details. Emacs uses a pseudo tty. I'm currently
using the latest Cygwin snapshot, but I'm pretty sure I saw the same
behavior with 1.7.9. I'll recheck that. My workaround is to force
emacs to check for process output earlier in the initialization phase.
For reasons I don't understand, the select call used at that point
always succeeds.
I think you've answered my basic question by saying that the EINTR
sounds weird. I'll try to make a testcase.
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
next prev parent reply other threads:[~2011-10-19 15:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-19 13:29 Ken Brown
2011-10-19 14:49 ` Corinna Vinschen
2011-10-19 15:29 ` Ken Brown [this message]
2011-10-19 16:22 ` Christopher Faylor
2011-10-19 17:32 ` Ken Brown
2011-10-19 20:15 ` Ken Brown
2011-10-19 20:31 ` Jon Clugston
2011-10-20 2:39 ` Ken Brown
2011-10-20 12:14 ` Ken Brown
2011-10-21 9:45 ` Corinna Vinschen
2011-10-21 14:27 ` Ken Brown
2011-10-21 15:45 ` Jon Clugston
2011-10-21 20:03 ` Ken Brown
2011-10-22 9:55 ` Ken Brown
2011-10-22 20:42 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E9EECDB.8020005@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).