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