[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Signals and input

From: Eli Zaretskii
Subject: Signals and input
Date: Thu, 27 Sep 2012 20:40:35 +0200

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

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

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

  /* 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.  */
  #define POLL_FOR_INPUT

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]