Question about Cygwin's select()

Question about Cygwin's select()

[Ken Brown]

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.

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

Re: Question about Cygwin's select()

[Corinna Vinschen]

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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Question about Cygwin's select()

[Ken Brown]

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

Re: Question about Cygwin's select()

[Christopher Faylor]

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.

cgf

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

Re: Question about Cygwin's select()

[Ken Brown]

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

Re: Question about Cygwin's select()

[Ken Brown]

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


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

Re: Question about Cygwin's select()

[Jon Clugston]

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

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

Re: Question about Cygwin's select()

[Ken Brown]

On 10/19/2011 4:15 PM, Ken Brown wrote:
> 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.

I think this guess is correct.  If I start up emacs and do nothing, 
strace shows many sequences like the following:

  - emacs calls select
  - a timer sends SIGALRM
  - select returns -1 with error EINTR

The EINTR isn't actually visible in the strace output, but I do see 
"select_stuff::wait: signal received".  A glance at select.cc indicates 
that this is the debug output produced by select when it is about to 
return -1 with EINTR.

These sequences always occur in connection with start_thread_socket. 
I've appended a typical excerpt from the strace output below.  Please 
let me know if you need to see more strace output.  I didn't want to 
spam the list by sending too much.

You still might need more information, but I can at least refine my 
original question:  Is it reasonable that select should give up and 
return -1 because a timer has sent SIGALRM?

Ken

[...]
   686 8226742 [main] emacs 6772 cygwin_select: 6, 0x28C134, 0x28C12C, 
0x0, 0x28C200
[...]
   106 8227514 [main] emacs 6772 select_stuff::wait: m 4, ms 464
    49 8227563 [select_socket] emacs 6772 thread_socket: stuff_start 
0x28C098
    53 8227616 [select_socket] emacs 6772 peek_socket: read_ready: 0, 
write_ready: 0, except_ready: 0
  2501 8230117 [itimer] emacs 6772 timer_thread: timed out
    66 8230183 [itimer] emacs 6772 timer_thread: 0x6118D560 sending sig 14
    52 8230235 [itimer] emacs 6772 sig_send: sendsig 0x104, pid 6772, 
signal 14, its_me 1
    52 8230287 [itimer] emacs 6772 sig_send: Not waiting for 
sigcomplete.  its_me 1 signal 14
     5 8230292 [sig] emacs 6772 sigpacket::process: signal 14 processing
    35 8230327 [itimer] emacs 6772 sig_send: returning 0x0 from sending 
signal 14
    28 8230355 [sig] emacs 6772 _cygtls::find_tls: sig 14
    61 8230416 [sig] emacs 6772 sigpacket::process: signal 14, about to 
call 0x5E85A8
    37 8230453 [sig] emacs 6772 setup_handler: controlled interrupt. 
stackptr 0x28DA34, stack 0x28DA30, stackptr[-1] 0x4F2F4C
[...]
    35 8230632 [sig] emacs 6772 _cygtls::interrupt_setup: armed 
signal_arrived 0x154, sig 14, res 1
    57 8230689 [sig] emacs 6772 setup_handler: signal 14 delivered
    40 8230729 [sig] emacs 6772 sigpacket::process: returning 1
    51 8230780 [main] emacs 6772 select_stuff::cleanup: calling cleanup 
routines
   596 8231376 [main] emacs 6772 socket_cleanup: si 0x8016D220 
si->thread 0x611773F0
   307 8231683 [select_socket] emacs 6772 thread_socket: leaving 
thread_socket
   696 8232379 [main] emacs 6772 socket_cleanup: returning
    56 8232435 [main] emacs 6772 select_stuff::wait: signal received




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

Re: Question about Cygwin's select()

[Corinna Vinschen]

On Oct 20 08:13, Ken Brown wrote:
> On 10/19/2011 4:15 PM, Ken Brown wrote:
> >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.
> 
> I think this guess is correct.  If I start up emacs and do nothing,
> strace shows many sequences like the following:
> 
>  - emacs calls select
>  - a timer sends SIGALRM
>  - select returns -1 with error EINTR
> 
> The EINTR isn't actually visible in the strace output, but I do see
> "select_stuff::wait: signal received".  A glance at select.cc
> indicates that this is the debug output produced by select when it
> is about to return -1 with EINTR.
> 
> These sequences always occur in connection with start_thread_socket.
> I've appended a typical excerpt from the strace output below.
> Please let me know if you need to see more strace output.  I didn't
> want to spam the list by sending too much.
> 
> You still might need more information, but I can at least refine my
> original question:  Is it reasonable that select should give up and
> return -1 because a timer has sent SIGALRM?

If SIGALRM isn't blocked, then, yes.  What is setting up the timer?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Question about Cygwin's select()

[Ken Brown]

On 10/21/2011 5:44 AM, Corinna Vinschen wrote:
> On Oct 20 08:13, Ken Brown wrote:
>> On 10/19/2011 4:15 PM, Ken Brown wrote:
>>> 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.
>>
>> I think this guess is correct.  If I start up emacs and do nothing,
>> strace shows many sequences like the following:
>>
>>   - emacs calls select
>>   - a timer sends SIGALRM
>>   - select returns -1 with error EINTR
>>
>> The EINTR isn't actually visible in the strace output, but I do see
>> "select_stuff::wait: signal received".  A glance at select.cc
>> indicates that this is the debug output produced by select when it
>> is about to return -1 with EINTR.
>>
>> These sequences always occur in connection with start_thread_socket.
>> I've appended a typical excerpt from the strace output below.
>> Please let me know if you need to see more strace output.  I didn't
>> want to spam the list by sending too much.
>>
>> You still might need more information, but I can at least refine my
>> original question:  Is it reasonable that select should give up and
>> return -1 because a timer has sent SIGALRM?
>
> If SIGALRM isn't blocked, then, yes.  What is setting up the timer?

Emacs sets up the timer.  But I just looked at the code in which emacs 
calls select, and it looks like it reduces the select timeout to make 
sure that select will return before the next SIGALRM is expected.  I 
don't know why that's not working.

By the way, I added debug code to emacs to make it print the return 
value after every call to select.  If I then start emacs and do nothing, 
I get a message every second or two saying that select failed.  If I 
press a key, select succeeds once or twice before it starts failing again.

I'll keep trying to figure out what's going on.

Ken

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

Re: Question about Cygwin's select()

[Jon Clugston]

On Fri, Oct 21, 2011 at 10:26 AM, Ken Brown <kbrown@cornell.edu> wrote:
> On 10/21/2011 5:44 AM, Corinna Vinschen wrote:
>>
>> On Oct 20 08:13, Ken Brown wrote:
>>>
>>> On 10/19/2011 4:15 PM, Ken Brown wrote:
>>>>
>>>> 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.
>>>
>>> I think this guess is correct.  If I start up emacs and do nothing,
>>> strace shows many sequences like the following:
>>>
>>>  - emacs calls select
>>>  - a timer sends SIGALRM
>>>  - select returns -1 with error EINTR
>>>
>>> The EINTR isn't actually visible in the strace output, but I do see
>>> "select_stuff::wait: signal received".  A glance at select.cc
>>> indicates that this is the debug output produced by select when it
>>> is about to return -1 with EINTR.
>>>
>>> These sequences always occur in connection with start_thread_socket.
>>> I've appended a typical excerpt from the strace output below.
>>> Please let me know if you need to see more strace output.  I didn't
>>> want to spam the list by sending too much.
>>>
>>> You still might need more information, but I can at least refine my
>>> original question:  Is it reasonable that select should give up and
>>> return -1 because a timer has sent SIGALRM?
>>
>> If SIGALRM isn't blocked, then, yes.  What is setting up the timer?
>
> Emacs sets up the timer.  But I just looked at the code in which emacs calls
> select, and it looks like it reduces the select timeout to make sure that
> select will return before the next SIGALRM is expected.  I don't know why
> that's not working.

There is absolutely no guarantee that you can do that.  If the process
is put to sleep between the computation of the select timeout and the
actual call to "select", this logic fails.  If the code assumes that
it can reliably cause "select" to time out before a pending alarm
expires, then it is broken.


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

Re: Question about Cygwin's select()

[Ken Brown]

On 10/21/2011 11:45 AM, Jon Clugston wrote:
> On Fri, Oct 21, 2011 at 10:26 AM, Ken Brown<kbrown@cornell.edu>  wrote:
>> On 10/21/2011 5:44 AM, Corinna Vinschen wrote:
>>>
>>> On Oct 20 08:13, Ken Brown wrote:
>>>>
>>>> On 10/19/2011 4:15 PM, Ken Brown wrote:
>>>>>
>>>>> 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.
>>>>
>>>> I think this guess is correct.  If I start up emacs and do nothing,
>>>> strace shows many sequences like the following:
>>>>
>>>>   - emacs calls select
>>>>   - a timer sends SIGALRM
>>>>   - select returns -1 with error EINTR
>>>>
>>>> The EINTR isn't actually visible in the strace output, but I do see
>>>> "select_stuff::wait: signal received".  A glance at select.cc
>>>> indicates that this is the debug output produced by select when it
>>>> is about to return -1 with EINTR.
>>>>
>>>> These sequences always occur in connection with start_thread_socket.
>>>> I've appended a typical excerpt from the strace output below.
>>>> Please let me know if you need to see more strace output.  I didn't
>>>> want to spam the list by sending too much.
>>>>
>>>> You still might need more information, but I can at least refine my
>>>> original question:  Is it reasonable that select should give up and
>>>> return -1 because a timer has sent SIGALRM?
>>>
>>> If SIGALRM isn't blocked, then, yes.  What is setting up the timer?
>>
>> Emacs sets up the timer.  But I just looked at the code in which emacs calls
>> select, and it looks like it reduces the select timeout to make sure that
>> select will return before the next SIGALRM is expected.  I don't know why
>> that's not working.
>
> There is absolutely no guarantee that you can do that.  If the process
> is put to sleep between the computation of the select timeout and the
> actual call to "select", this logic fails.  If the code assumes that
> it can reliably cause "select" to time out before a pending alarm
> expires, then it is broken.

You're right.  Blocking SIGALRM before the call to select (in the 
situation where the timeout was reduced) seems to fix the problem.  I 
still have to do some more testing, but so far it looks good.

Thanks.

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

Re: Question about Cygwin's select()

[Ken Brown]

On 10/21/2011 4:03 PM, Ken Brown wrote:
> On 10/21/2011 11:45 AM, Jon Clugston wrote:
>> On Fri, Oct 21, 2011 at 10:26 AM, Ken Brown<kbrown@cornell.edu> wrote:
>>> On 10/21/2011 5:44 AM, Corinna Vinschen wrote:
>>>>
>>>> On Oct 20 08:13, Ken Brown wrote:
>>>>>
>>>>> On 10/19/2011 4:15 PM, Ken Brown wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> I think this guess is correct. If I start up emacs and do nothing,
>>>>> strace shows many sequences like the following:
>>>>>
>>>>> - emacs calls select
>>>>> - a timer sends SIGALRM
>>>>> - select returns -1 with error EINTR
>>>>>
>>>>> The EINTR isn't actually visible in the strace output, but I do see
>>>>> "select_stuff::wait: signal received". A glance at select.cc
>>>>> indicates that this is the debug output produced by select when it
>>>>> is about to return -1 with EINTR.
>>>>>
>>>>> These sequences always occur in connection with start_thread_socket.
>>>>> I've appended a typical excerpt from the strace output below.
>>>>> Please let me know if you need to see more strace output. I didn't
>>>>> want to spam the list by sending too much.
>>>>>
>>>>> You still might need more information, but I can at least refine my
>>>>> original question: Is it reasonable that select should give up and
>>>>> return -1 because a timer has sent SIGALRM?
>>>>
>>>> If SIGALRM isn't blocked, then, yes. What is setting up the timer?
>>>
>>> Emacs sets up the timer. But I just looked at the code in which emacs
>>> calls
>>> select, and it looks like it reduces the select timeout to make sure
>>> that
>>> select will return before the next SIGALRM is expected. I don't know why
>>> that's not working.
>>
>> There is absolutely no guarantee that you can do that. If the process
>> is put to sleep between the computation of the select timeout and the
>> actual call to "select", this logic fails. If the code assumes that
>> it can reliably cause "select" to time out before a pending alarm
>> expires, then it is broken.
>
> You're right. Blocking SIGALRM before the call to select (in the
> situation where the timeout was reduced) seems to fix the problem.

I'm wrong.  I've been focusing too much on the select interruption. 
This is actually harmless and is correctly treated by emacs the same as 
a select timeout.  It doesn't explain or solve the original gdb problem. 
  Sorry for the noise.

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

Re: Question about Cygwin's select()

[Ken Brown]

On 10/22/2011 5:55 AM, Ken Brown wrote:
> I'm wrong. I've been focusing too much on the select interruption. This
> is actually harmless and is correctly treated by emacs the same as a
> select timeout. It doesn't explain or solve the original gdb problem.
> Sorry for the noise.

I was finally able to make a testcase, showing that the problem I 
mentioned in the first post of this thread has nothing to do with emacs 
or select.  It's a Cygwin/gdb problem.  I've reported it in

   http://cygwin.com/ml/cygwin/2011-10/msg00445.html

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