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
