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

[GNU bug Tracking System]

Your message dated Wed, 17 Nov 2021 13:11:06 -0500
with message-id <c030d4b3-4723-0fe5-9d67-9fc668e62698@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@gnu.org.)


-- 
51820: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51820
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 29.0.50; process_pending_signals is almost useless without SIGIO
>
>
>
>
> Date: 
>
> Sat, 13 Nov 2021 17:49:59 -0500
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
>
>
>
>
> 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
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#51820: 29.0.50; process_pending_signals is almost useless without SIGIO
>
>
>
>
> Date: 
>
> Wed, 17 Nov 2021 13:11:06 -0500
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1
>
>
>
>
> 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
>
>
> --- End Message ---