Re: alarm_signal_handler is called too frequently

[Richard Stallman <rms@gnu.org>]

    > For example, BLOCK_INPUT occurs when a popup menu is activated.
    > Then the menu takes control of the user input, and BLOCK_INPUT
    > continues until the user complete the menu operation.

    The frequent call of alarm_signal_handler was observed also on
    GNU/Linux (with or without GTK) during a popup menu was shown.  Could
    someone answer the original question below?

I looked at this just now (please forgive the delay) and found that
things seem to be rather messed up.

1. The code makes provision to handle unexpected kinds of
keyboard/mouse input while the popup menu is popped up, and to handle
timers.  That is a nice feature.

2. However, popup_get_selection is called inside BLOCK_INPUT, and it
calls timer_check, which can call Lisp code.  This seems to be a bug.

I don't see any way we could make this safe.  I think we have to
take out timer processing here.  However, I have some doubt that
it really works--see below.

3. popup_get_selection is called whenever USE_GTK is not defined, but
popup_get_selection is only defined when USE_X_TOOLKIT.  I suspect
this means that Emacs won't build in the non-toolkit mode any more.
Could someone check?


I propose the following change as a way to discover problems like #2
sooner.  Could people try it and say if it crashes?  (Strangely, it
does not crash for me when I try C-Mouse-3 just after enabling Font
Lock mode on emacs.c.  I wonder why.)


*** eval.c	30 Jul 2004 23:43:15 -0400	1.221
--- eval.c	25 Oct 2004 05:34:28 -0400	
***************
*** 1975,1981 ****
    struct backtrace backtrace;
    struct gcpro gcpro1, gcpro2, gcpro3;
  
!   if (handling_signal)
      abort ();
  
    if (SYMBOLP (form))
--- 1985,1991 ----
    struct backtrace backtrace;
    struct gcpro gcpro1, gcpro2, gcpro3;
  
!   if (handling_signal || INPUT_BLOCKED_P)
      abort ();
  
    if (SYMBOLP (form))