From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Signals and input Date: Thu, 27 Sep 2012 20:40:35 +0200 Message-ID: <83lifvgvh8.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1348771280 11892 80.91.229.3 (27 Sep 2012 18:41:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Sep 2012 18:41:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 27 20:41:23 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1THJ1V-0003OD-Ow for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2012 20:41:21 +0200 Original-Received: from localhost ([::1]:46204 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THJ1Q-000373-MO for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2012 14:41:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THJ1N-00036n-IA for emacs-devel@gnu.org; Thu, 27 Sep 2012 14:41:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THJ1M-0006YH-JC for emacs-devel@gnu.org; Thu, 27 Sep 2012 14:41:13 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:60525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THJ1M-0006Xi-Aw for emacs-devel@gnu.org; Thu, 27 Sep 2012 14:41:12 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB000D00UFU7600@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 27 Sep 2012 20:40:34 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB000DCVUJM7J00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 27 Sep 2012 20:40:34 +0200 (IST) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153637 Archived-At: 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.