Signals and input

Signals and input

[Eli Zaretskii]

As part of the discussion in bug #12450, I asked which signals are
delivered when Emacs has input available, and got the following
answers:

> >>>> - The keyboard input or the X event causes a signal to be delivered.
> >>> Which signals are those, specifically?
> >> 
> >> SIGWINCH for window changes.
> >> 
> >> SIGIO, SIGINT and SIGQUIT for keyboard input, if interactive.
> >> But SIGIO is not used on platforms where it doesn't work.
> > 
> > Thanks, but what about X input events?
> 
> SIGIO.

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.

P.S.  Is the comment above still accurate, btw?  If so, it should be
made more clear: is POLL_FOR_INPUT really only for C-g?  And what does
it mean "not used when doing interrupt input"? how is polling avoided
"when doing interrupt input"?

P.P.S.  We have a similar #ifdef in process.c -- sounds like we should
move this to some header shared by those two.

Re: Signals and input

[Eli Zaretskii]

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