public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Jon Clugston <jon.clugston@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Question about Cygwin's select()
Date: Wed, 19 Oct 2011 20:31:00 -0000	[thread overview]
Message-ID: <CAG_2cT=n-a0ay0WOwv181nUHG9UAN=uW+CGpza9P15ZEGQGnnQ@mail.gmail.com> (raw)
In-Reply-To: <4E9F2FE1.7050003@cornell.edu>

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.

Jon

--
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

  reply	other threads:[~2011-10-19 20:31 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
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 [this message]
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='CAG_2cT=n-a0ay0WOwv181nUHG9UAN=uW+CGpza9P15ZEGQGnnQ@mail.gmail.com' \
    --to=jon.clugston@gmail.com \
    --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).