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.