UNBLOCK_INPUT again...

UNBLOCK_INPUT again...

[David Kastrup]

[-- 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

Re: UNBLOCK_INPUT again...

[Jan D.]

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.

Re: UNBLOCK_INPUT again...

[Stefan Monnier]

> I think we should try to get SYNC_INPUT to work.

Works for me.


        Stefan

Re: UNBLOCK_INPUT again...

[Jan D.]

2005-03-04 kl. 20.36 skrev Stefan Monnier:

>> I think we should try to get SYNC_INPUT to work.
>
> Works for me.
>

For me too.  But it is probably too untested to turn on by default for 
this release?

	Jan D.

Re: UNBLOCK_INPUT again...

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> 2005-03-04 kl. 20.36 skrev Stefan Monnier:
>
>>> I think we should try to get SYNC_INPUT to work.
>>
>> Works for me.
>>
>
> For me too.  But it is probably too untested to turn on by default for
> this release?

I think it would be madness to turn it on just because I have some
problems understanding the code and all its implications.  At least if
we have no problems reported with the current code currently.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: UNBLOCK_INPUT again...

[Jan D.]

>>>> I think we should try to get SYNC_INPUT to work.
>>>
>>> Works for me.
>>>
>>
>> For me too.  But it is probably too untested to turn on by default for
>> this release?
>
> I think it would be madness to turn it on just because I have some
> problems understanding the code and all its implications.  At least if
> we have no problems reported with the current code currently.

There are problems from time to time that would never have happened in 
the SYNC_INPUT case.  Also, it would be easier to change so that a 
separate thread does what the signal handler does now.

	Jan D.

Re: UNBLOCK_INPUT again...

[Stefan Monnier]

> For me too.  But it is probably too untested to turn on by default for
> this release?

Of course, changing it before the release is out of the question.


        Stefan

Re: UNBLOCK_INPUT again...

[Richard Stallman]

I wrote code to take care of this, but had no chance to install it
until today.