diff src/event-xlike-inc.c @ 1268:fffe735e63ee

[xemacs-hg @ 2003-02-07 11:50:50 by ben] fixes for menu crashes + better preemption behavior This contains two related changes: (1) Fix problems with reentrant calling of lwlib and associated crashes when selecting menu items. (2) Improve redisplay handling of preemption. Turn on lazy lock and hold down page-down or page-up and you'll see what I mean. They are related because they both touch on the code that retrieves events and handles the internal queues. console-msw.h, event-msw.c, event-stream.c, events.h, menubar-msw.c, menubar-x.c, menubar.h: mswindows_protect_modal_loop() has been generalized to event_stream_protect_modal_loop(), and moved to event-stream.c. mswindows_in_modal_loop ->in_modal_loop likewise. Changes in event-msw.c and menubar-msw.c for the new names and calling format (use structures instead of static variables in menubar-msw.c). Delete former in_menu_callback and use in_modal_loop in its place. Remove emacs_mswindows_quit_check_disallowed_p(), superseded by in_modal_loop. Use event_stream_protect_modal_loop() in pre_activate_callback() so that we get no lwlib reentrancy. Rearrange some of the code in event-msw.c to be grouped better. Make mswindows_drain_windows_queue() respect in_modal_loop and do nothing if so. cmdloop.c, event-stream.c: Don't conditionalize on LWLIB_MENUBARS_LUCID when giving error when in_modal_loop, and give better error. event-Xt.c, event-gtk.c: If in_modal_loop, only retrieve process and timeout events. Don't retrieve any X events because processing them can lead to reentrancy in lwlib -> death. event-stream.c: Remove unused parameter to check_event_stream_ok() and change all callers. lisp.h, event-stream.c: Rearrange some functions for increased clarity -- in particular, group all the input-pending/QUIT-related stuff together, and put right next to next-event stuff, to which it's related. Add the concept of "HOW_MANY" -- when asking whether user input is pending, you can ask if at least HOW_MANY events are pending, not just if any are. Add parameter to detect_input_pending() for this. Change recursive_sit_for from a Lisp_Object (which could only be Qt or Qnil) to an int, like it should be. event-Xt.c, event-gtk.c, event-xlike-inc.c: New file. Abstract out similar code in event_{Xt/gtk}_pending_p() and write only once, using include-file tricks. Rewrite this function to implement HOW_MANY and only process events when not in_modal_loop. event-msw.c: Implement HOW_MANY and only process events when not in_modal_loop. event-tty.c: Implement HOW_MANY. redisplay.c: Add var `max-preempts' to control maximum number of preempts. (#### perhaps not useful) Rewrite preemption check so that, rather than preempting when any user events are available, only preempt when a certain number (currently 4) of them are backed up. This effectively allows redisplay to proceed to completion in the presence of a fast auto-repeat (usually the auto-repeating is generated dynamically as necessary), and you get much better display behavior with lazy-lock active. event-unixoid.c: Comment changes. event-stream.c: Rewrite discard-input much more simply and safely using the drain-queue functions. I think the old version might loop forever if called when in_modal_loop. SEMI-UNRELATED CHANGES: ----------------------- event-stream.c: Turn QUIT-checking back on when running the pre-idle hook so it can be quit out of. indent.c: Document exact functioning of `vertical-motion' better, and its differences from GNU Emacs.
author ben
date Fri, 07 Feb 2003 11:50:54 +0000
parents
children a25c824ed558
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/event-xlike-inc.c	Fri Feb 07 11:50:54 2003 +0000
@@ -0,0 +1,161 @@
+/* Shared event code between X and GTK -- include file.
+   Copyright (C) 1991-5, 1997 Free Software Foundation, Inc.
+   Copyright (C) 1995 Sun Microsystems, Inc.
+   Copyright (C) 1996, 2001, 2002, 2003 Ben Wing.
+
+This file is part of XEmacs.
+
+XEmacs is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the
+Free Software Foundation; either version 2, or (at your option) any
+later version.
+
+XEmacs is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with XEmacs; see the file COPYING.  If not, write to
+the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* Synched up with: Not in FSF. */
+
+/* For some code it's reasonable to have only one copy and conditionalize
+   at run-time.  For other code it isn't. #### Perhaps all code should be
+   included here, not in event-xlike.c.  However, event-xlike.c is always
+   X-specific, whereas the following code isn't, in the GTK case. */
+
+static int
+#ifdef THIS_IS_GTK
+emacs_gtk_event_pending_p (int how_many)
+#else
+emacs_Xt_event_pending_p (int how_many)
+#endif
+{
+  Lisp_Object event;
+  int tick_count_val;
+
+  /* If `how_many' is 0, then this function returns whether there are any
+     X, timeout, or fd events pending (that is, whether
+     emacs_Xt_next_event() would return immediately without blocking).
+
+     If `how_many' is > 0, then this function returns whether there are
+     that many *user generated* events available (keyboard, mouse click,
+     etc.).  This also implies that emacs_Xt_next_event() would not block.
+   */
+
+  /* This function used to simply check whether there were any X events (or
+     if user_p was 1, it iterated over all the pending X events using
+     XCheckIfEvent(), looking for keystrokes and button events).  That
+     worked in the old cheesoid event loop, which didn't go through
+     XtAppDispatchEvent(), but it doesn't work any more -- X events may not
+     result in anything.  For example, a button press in a blank part of
+     the menubar appears as an X event but will not result in any Emacs
+     events (a button press that activates the menubar results in an Emacs
+     event through the stop_next_event mechanism).
+
+     The only accurate way of determining whether these X events translate
+     into Emacs events is to go ahead and dispatch them until there's
+     something on the dispatch queue. */
+
+  if (!how_many)
+    {
+      /* We're being asked for *ALL* events, not just user events. */
+
+      /* (1) Any pending events in the dispatch queue? */
+      if (!NILP (dispatch_event_queue))
+	return 1;
+
+      /* (2) Any TTY or process input available?
+
+	 Note that formerly we just checked the value of XtAppPending() to
+	 determine if there was file-desc input.  This doesn't work any
+	 more with the signal_event_pipe; XtAppPending() will says "yes" in
+	 this case but there isn't really any input.  So instead we keep
+	 track of the file descriptors, and call select() ourselves.
+	 Another way of fixing this problem is for the signal_event_pipe to
+	 generate actual input in the form of an identity eval event or
+	 something. (#### maybe this actually happens?) */
+
+      if (poll_fds_for_input (non_fake_input_wait_mask))
+	return 1;
+
+#ifndef THIS_IS_GTK
+      /* (3) Any timeout input available? */
+      if (XtAppPending (Xt_app_con) & XtIMTimer)
+	return 1;
+#else
+      /* #### Is there any way to do this in Gtk?  I don't think there
+              is a 'peek' for events */
+#endif
+    }
+  else
+    {
+      /* HOW_MANY > 0 */
+      EVENT_CHAIN_LOOP (event, dispatch_event_queue)
+	{
+	  if (command_event_p (event))
+	    {
+	      how_many--;
+	      if (how_many <= 0)
+		return 1;
+	    }
+	}
+    }
+
+  /* XtAppPending() can be super-slow, esp. over a network connection.
+     Quantify results have indicated that in some cases the call to
+     detect_input_pending() completely dominates the running time of
+     redisplay().  Fortunately, in a SIGIO world we can more quickly
+     determine whether there are any X events: if an event has happened
+     since the last time we checked, then a SIGIO will have happened.  On a
+     machine with broken SIGIO, we'll still be in an OK state --
+     quit_check_signal_tick_count will get ticked at least every 1/4
+     second, so we'll be no more than that much behind reality. (In general
+     it's OK if we erroneously report no input pending when input is
+     actually pending() -- preemption is just a bit less efficient, that's
+     all.  It's bad bad bad if you err the other way -- you've promised
+     that `next-event' won't block but it actually will, and some action
+     might get delayed until the next time you hit a key.)
+     */
+
+  if (!in_modal_loop)
+    {
+      /* quit_check_signal_tick_count is volatile so try to avoid race
+	 conditions by using a temporary variable */
+      tick_count_val = quit_check_signal_tick_count;
+      if (last_quit_check_signal_tick_count != tick_count_val
+#if !defined (THIS_IS_GTK) && (!defined (SIGIO) || defined (CYGWIN))
+	  || (XtIMXEvent & XtAppPending (Xt_app_con))
+#endif 
+	  )
+	{
+	  last_quit_check_signal_tick_count = tick_count_val;
+
+	  /* We need to drain the entire queue now -- if we only drain part of
+	     it, we may later on end up with events actually pending but
+	     detect_input_pending() returning false because there wasn't
+	     another SIGIO. */
+	  event_stream_drain_queue ();
+
+	  if (!how_many)
+	    return !NILP (dispatch_event_queue);
+
+	  EVENT_CHAIN_LOOP (event, dispatch_event_queue)
+	    {
+	      if (command_event_p (event))
+		{
+		  how_many--;
+		  if (how_many <= 0)
+		    return 1;
+		}
+	    }
+
+	  return 0;
+	}
+    }
+
+  return 0;
+}