GNU bug report logs - #51820
29.0.50; process_pending_signals is almost useless without SIGIO

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ken Brown <kbrown <at> cornell.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#51820: closed (29.0.50; process_pending_signals is almost
 useless without SIGIO)
Date: Wed, 17 Nov 2021 18:12:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 17 Nov 2021 13:11:06 -0500
with message-id <c030d4b3-4723-0fe5-9d67-9fc668e62698 <at> cornell.edu>
and subject line Re: bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO
has caused the debbugs.gnu.org bug report #51820,
regarding 29.0.50; process_pending_signals is almost useless without SIGIO
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
51820: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51820
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; process_pending_signals is almost useless without SIGIO
Date: Sat, 13 Nov 2021 17:49:59 -0500

I might be missing something, but it seems to me that the main purpose of 
process_pending_signals is to read input in case the user typed C-g.  This is in 
fact done on systems with SIGIO, via a call to handle_async_input.  But 
handle_async_input is a NOOP on systems without SIGIO.  This has been the case 
since the following commit:

commit 4d7e6e51dd4acecff466a28d958c50f34fc130b8
Author: Paul Eggert <eggert <at> cs.ucla.edu>
Date:   Sun Sep 23 01:44:20 2012 -0700

    Simplify and avoid signal-handling races.
[...]
    Fixes: debbugs:12471

I can't find anything in the commit message or in the discussion of Bug#12471 
that explains this.  Paul, I realize that the commit was 9 years ago, but do you 
remember why you made this change?

On systems without SIGIO, an atimer "poll_timer" is created that fires every 2 
seconds.  This causes pending_signals to be set, which has practically no effect 
AFAICT.  The only thing I see that poll_timer accomplishes is that if emacs 
happens to be in the select call in wait_reading_process_output when the timer 
fires, then select will return.

Ken

[Message part 3 (message/rfc822, inline)]

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 51820-done <at> debbugs.gnu.org
Subject: Re: bug#51820: 29.0.50; process_pending_signals is almost useless
 without SIGIO
Date: Wed, 17 Nov 2021 13:11:06 -0500

On 11/14/2021 1:48 AM, Eli Zaretskii wrote:
>> Date: Sat, 13 Nov 2021 18:25:55 -0500
>> Cc: 51820 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
>> From: Ken Brown <kbrown <at> cornell.edu>
>>
>>> In that case, perhaps someone using Cygwin (i.e., not me) could look into this.
>>> Evidently it has not been much of a practical problem all these years.
>>
>> It's hard to know whether it's been a problem.  Maybe emacs would be more
>> responsive to C-g on Cygwin if we removed the #ifdef from handle_async_input.
>> My preference would be to try that (on master of course) and see if anything breaks.
>>
>> Eli, WDYT?
> 
> Sure, feel free to install such a change on master.

Done.

> I don't know how
> many Cygwin users track the Emacs master branch, but if there are more
> than a couple, perhaps even provide a variable exposed to Lisp that
> users could tweak to see the result without rebuilding and without
> leaving the session.

Good idea.  I think I'll wait a couple weeks so that I can see how the change 
works myself, as well as to see if anyone notices.  But then I might do that. 
For now I'm closing the bug.

Ken

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.