Mercurial > hg > xemacs-beta
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; +}