[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Signals and input
Signals and input
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. */
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.
- Signals and input,
Eli Zaretskii <=