[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UNBLOCK_INPUT again...

From: Jan D.
Subject: Re: UNBLOCK_INPUT again...
Date: Fri, 04 Mar 2005 19:14:50 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

David Kastrup wrote:


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

+#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.  */

  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

This does happen. For example, screen updates (expose events from X) does get handeled before the catch when UNBLOCK is called and interrupt_input_blocked goes to zero. I don't think this is a bad idea. Pending timers is perhaps not a good idea, depending on how much code they execute. But I don't think they execute lisp code as they are executing in a signal handler (normally at least). I guess you should not throw from a signal handler either.

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.

No, this does not look right. We might loose events (or at least not handle them at once). unwind_to_catch should check if interrupt_input_blocked is zero after restoring it and then do the pending stuff if it is. Or this could be done where the setjmp:s are called.

Could somebody with somewhat more of a clue than myself say something

Hmm, not easy to do. There doesn't seem to be anyone that is really comfortable with this code. I think we should try to get SYNC_INPUT to work. That should simplify a few bits.

   Jan D.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]