bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9767: 24.0.90; gdb initialization on Cygwin


From: Ken Brown
Subject: bug#9767: 24.0.90; gdb initialization on Cygwin
Date: Fri, 21 Oct 2011 16:47:52 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

On 10/19/2011 10:11 PM, Ken Brown wrote:
On 10/19/2011 6:02 PM, Eli Zaretskii wrote:
From: Andreas Schwab<address@hidden>
Cc: Eli Zaretskii<address@hidden>, address@hidden
Date: Wed, 19 Oct 2011 23:03:23 +0200

Ken Brown<address@hidden> writes:

No, wait_reading_process_output treats EINTR as though it meant
there's no
input available.

Which is correct because an interrupted select does not report anything.
And then the loop will be restarted to call select again.

Yes, that's what I thought should be happening. Sorry if that was
unclear.

You were clear. I was the one who muddied the waters by misreading the
code, and Andreas correctly pointed out that I was wrong.

So the question is still why no input is being reported, although
wait_reading_process_output should loop and call `select' again.

Yes, that's the question. I'll have to go back to my debugging.

OK, I figured out what's happening, and it is related to SIGALRM after all. In line 4406 of process.c, wait_reading_process_output reduces the timeout for the select call (under certain circumstances) in an attempt to prevent select from being interrupted by SIGALRM. This seems to me to be inherently unreliable, and, in particular, it consistently fails on Cygwin. In other words, the SIGALRM is delivered before select times out, causing select to get interrupted. So wait_reading_process_output does indeed loop, and select fails every time (except when a key is pressed).

If I block SIGALRM before the call to select (in the situation where the timeout was reduced), the problem is solved. I need to do some more testing, but so far I don't see any sign that this causes other problems.

One tricky thing is that blocking SIGALRM has to be done right before the call to the *system* select. In the build with GTK support, this call is inside xg_select, and things break if SIGALRM is blocked before the call to xg_select. So I'm not sure what's the best way to handle this. I'll keep thinking about it, but suggestions are welcome.

Ken





reply via email to

[Prev in Thread] Current Thread [Next in Thread]