Hi,
I mentioned that throws already restore the value of
interrupt_input_blocked and so that doing so manually in keyboard.c
would seem unnecessary. That would suggest the following patch:
--- keyboard.c 16 Feb 2005 02:07:09 +0100 1.811
+++ keyboard.c 01 Mar 2005 06:07:13 +0100
@@ -1350,10 +1350,13 @@
cancel_hourglass ();
#endif
+#if 0
+ Throwing already resets the blocked counter.
/* Unblock input if we enter with input blocked. This may happen if
redisplay traps e.g. during tool-bar update with input blocked. */
while (INPUT_BLOCKED_P)
UNBLOCK_INPUT;
+#endif
return Fthrow (Qtop_level, Qnil);
}
However, this is somewhat incorrect as an analysis, since
UNBLOCK_INPUT does additional action when the count returns to zero.
It is defined as:
#define UNBLOCK_INPUT \
do \
{ \
--interrupt_input_blocked; \
if (interrupt_input_blocked == 0) \
{ \
if (interrupt_input_pending) \
reinvoke_input_signal (); \
if (pending_atimers) \
do_pending_atimers (); \
} \
else if (interrupt_input_blocked < 0) \
abort (); \
} \
while (0)
Now with the current approach, in keyboard.c pending timers and stuff
will get run _before_ doing the actual throw. I don't know whether
this is a good idea. In particular if the circumstances are such that
the catch is in a situation resulting in a nonzero
interrupt_input_blocked (I don't know whether this can actually
happen).
On the other hand, when something actually gets thrown from anywhere
else, interrupt_input_blocked may get restored to zero _without_
running the pending stuff (almost all catches are in eval.c). That
does not look quite right either.
Could somebody with somewhat more of a clue than myself say something
soothing?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
