Re: Signals and input

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 27 Sep 2012 20:40:35 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Given this, there's something I don't understand: why do we force
> POLL_FOR_INPUT in an Emacs built for a window-system?  We have this in
> keyboard.c:
> 
>   /* If we support a window system, turn on the code to poll periodically
>      to detect C-g.  It isn't actually used when doing interrupt input.  */
>   #ifdef HAVE_WINDOW_SYSTEM
>   #define POLL_FOR_INPUT
>   #endif
> 
> If keyboard input and X events produce SIGIO, then why do we need to
> set up a timer that delivers SIGALRM every second of idle time for the
> purposes of polling input?  Aren't those SIGALRMs gratuitous,
> conducive to race conditions, etc. etc.?
> 
> What's more, HAVE_WINDOW_SYSTEM is a compile-time condition.  An Emacs
> built with it defined will turn on polling even in a purely TTY
> session, which doesn't seem to be needed at all (I think).
> 
> Can someone please help me see what am I missing?  TIA.

Answering my own question here: the missing link is the variable
interrupt_input.  It is set to 1 in init_keyboard if INTERRUPT_INPUT
is defined, and when non-zero, it effectively disables polling,
e.g. start_polling does nothing when that variable is non-zero.

If no one more knowledgeable beats me to it, I'll look into describing
this in the commentary near the beginning of keyboard.c.  I think we
should have there at least a high-level description of how Emacs does
input, similarly to what xdisp.c says about the display engine.