all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* UNBLOCK_INPUT again...
@ 2005-03-01 16:10 David Kastrup
  2005-03-04 18:14 ` Jan D.
  0 siblings, 1 reply; 8+ messages in thread
From: David Kastrup @ 2005-03-01 16:10 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 193 bytes --]


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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 449 bytes --]

--- 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);
 }

[-- Attachment #3: Type: text/plain, Size: 1215 bytes --]


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

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-03-05 16:59 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-01 16:10 UNBLOCK_INPUT again David Kastrup
2005-03-04 18:14 ` Jan D.
2005-03-04 19:36   ` Stefan Monnier
2005-03-04 19:45     ` Jan D.
2005-03-04 21:03       ` David Kastrup
2005-03-04 22:11         ` Jan D.
2005-03-05 15:00       ` Stefan Monnier
2005-03-05 16:59   ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.