|
| 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:
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).
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 soothing?
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.
| [Prev in Thread] | Current Thread | [Next in Thread] |