UNBLOCK_INPUT again...

[David Kastrup]

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:

txtvQoKuMnDzB.txt
Description: Text Data

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