bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Ken Brown]

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

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Paul Eggert]

As I vaguely recall, every system using this code has SIGIO nowadays. It 
sounds like we should assume SIGIO here, and simplify the code 
accordingly, so as to avoid confusion in the future.

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Ken Brown]

On 11/13/2021 6:12 PM, Paul Eggert wrote:
> As I vaguely recall, every system using this code has SIGIO nowadays. It sounds 
> like we should assume SIGIO here, and simplify the code accordingly, so as to 
> avoid confusion in the future.

Cygwin uses this code and doesn't have SIGIO.

Ken

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Paul Eggert]

On 11/13/21 15:17, Ken Brown wrote:
> Cygwin uses this code and doesn't have SIGIO.

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.

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Ken Brown]

On 11/13/2021 6:18 PM, Paul Eggert wrote:
> On 11/13/21 15:17, Ken Brown wrote:
>> Cygwin uses this code and doesn't have SIGIO.
> 
> 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?

Ken

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Lars Ingebrigtsen]

Ken Brown <kbrown@cornell.edu> writes:

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

Also see bug#50043 -- there's other stuff that also doesn't work very
well without SIGIO.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Eli Zaretskii]

> Date: Sat, 13 Nov 2021 18:25:55 -0500
> Cc: 51820@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> From: Ken Brown <kbrown@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.  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.

Thanks.

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Ken Brown]

On 11/13/2021 9:26 PM, Lars Ingebrigtsen wrote:
> Ken Brown <kbrown@cornell.edu> writes:
> 
>> 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.
> 
> Also see bug#50043 -- there's other stuff that also doesn't work very
> well without SIGIO.

Thanks, I'll take a look.

Ken

bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO

[Ken Brown]

On 11/14/2021 1:48 AM, Eli Zaretskii wrote:
>> Date: Sat, 13 Nov 2021 18:25:55 -0500
>> Cc: 51820@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>> From: Ken Brown <kbrown@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