* Signals and input
@ 2012-09-27 18:40 Eli Zaretskii
2012-09-29 14:49 ` Eli Zaretskii
0 siblings, 1 reply; 2+ messages in thread
From: Eli Zaretskii @ 2012-09-27 18:40 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Signals and input
2012-09-27 18:40 Signals and input Eli Zaretskii
@ 2012-09-29 14:49 ` Eli Zaretskii
0 siblings, 0 replies; 2+ messages in thread
From: Eli Zaretskii @ 2012-09-29 14:49 UTC (permalink / raw)
To: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-09-29 14:49 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-27 18:40 Signals and input Eli Zaretskii
2012-09-29 14:49 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).