alarm_signal_handler is called too frequently

alarm_signal_handler is called too frequently

[YAMAMOTO Mitsuharu]

I noticed that alarm_signal_handler was called too frequently on the
system that used polling with SIGALRM (such as Solaris/X11 and Mac OS
X/Carbon).  In alarm_signal_handler, set_alarm is called even when
interrupt_input_blocked is non-zero where no timer function is
executed.  If BLOCK_INPUT continues for a long time, which is typical
in Mac OS X/Carbon, set_alarm will set the timer value to 1000 usec
because the current time (now) exceeds the old expiration time
(atimers->expiration).  I think we don't have to call set_alarm when
pending_atimers is non-zero because do_pending_atimers is supposed to
be called eventually in such a case.  Is that correct?

The following patch also apparently reduces the CPU usage during the
idle time (~1.0% -> 0.0% on my PowerBook G4 667MHz).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/atimer.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/atimer.c,v
retrieving revision 1.16
diff -c -r1.16 atimer.c
*** src/atimer.c	19 Jul 2004 04:42:43 -0000	1.16
--- src/atimer.c	13 Oct 2004 00:56:47 -0000
***************
*** 397,403 ****
        EMACS_GET_TIME (now);
      }
  
!   set_alarm ();
  }
  
  
--- 397,404 ----
        EMACS_GET_TIME (now);
      }
  
!   if (!pending_atimers)
!     set_alarm ();
  }

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

    If BLOCK_INPUT continues for a long time, which is typical
    in Mac OS X/Carbon,

That sounds like a bug to me.  BLOCK_INPUT should only be set
for short periods of time.

Re: alarm_signal_handler is called too frequently

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 13 Oct 2004 10:43:24 -0400, Richard Stallman <rms@gnu.org> said:

>     If BLOCK_INPUT continues for a long time, which is typical in
> Mac OS X/Carbon,

> That sounds like a bug to me.  BLOCK_INPUT should only be set for
> short periods of time.

That's not unusual even in X11.  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.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: alarm_signal_handler is called too frequently

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 14 Oct 2004 14:16:25 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

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

>>>>> On Wed, 13 Oct 2004 10:15:53 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I think we don't have to call set_alarm when pending_atimers is
> non-zero because do_pending_atimers is supposed to be called
> eventually in such a case.  Is that correct?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

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

Re: alarm_signal_handler is called too frequently

[Jan D.]

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

It does (FWIW when I update from cvs I run a script that builds the GTK,
lesstif, motif, lucid, non-toolkit and non-X versions of Emacs to catch
errors like this).  That bit is inside a (rather long) section of 
ifdefs,
the structure is like this:

#if defined (USE_GTK) || defined (USE_X_TOOLKIT)
   /* popup_get_selection defined and used here.  */
#else  /* not USE_X_TOOLKIT && not USE_GTK */
   /* Non toolkit code  */
#endif

so popup_get_selection is not used for the non-toolkit build at all.

	Jan D.

>
>
> 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.)

It craches, but directly at start before any interaction.  Disabling the
toolbar (./emacs -q -xrm '*toolBar: 0') makes it start OK, but it does 
not
crash on any popup menu.  This is on GNU/Linux, toolkit, GTK and 
non-toolkit
versions.

	Jan D.

>
>
> *** 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))
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

    so popup_get_selection is not used for the non-toolkit build at all.

That means item 3 is not a real problem.  That is good.

    > 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 still think that is a real problem.

    It craches, but directly at start before any interaction.  Disabling the
    toolbar (./emacs -q -xrm '*toolBar: 0') makes it start OK, but it does 
    not
    crash on any popup menu.

1. If it does not crash with popup menus, that could be because no
timer was running.  Were there any timers that should have run?  Maybe
something else disables the running of timers from
popup_get_selection.  In that case, there is no bug here, but the code
to check timers is misleading.

2. Is popup_get_selection used, the way you compiled Emacs?

3. Can you debug the crash that does happen?  I think anything that
causes a crash with this patch has the potential to cause crashes
occasionally even without this patch.

Re: alarm_signal_handler is called too frequently

[Jan D.]

Richard Stallman wrote:

>     so popup_get_selection is not used for the non-toolkit build at all.
> 
> That means item 3 is not a real problem.  That is good.
> 
>     > 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 still think that is a real problem.
> 
>     It craches, but directly at start before any interaction.  Disabling the
>     toolbar (./emacs -q -xrm '*toolBar: 0') makes it start OK, but it does 
>     not
>     crash on any popup menu.
> 
> 1. If it does not crash with popup menus, that could be because no
> timer was running.  Were there any timers that should have run?  Maybe
> something else disables the running of timers from
> popup_get_selection.  In that case, there is no bug here, but the code
> to check timers is misleading.

Timers are running (scheduled), The version that uses Xt has a timer that runs 
every 0.1 seconds, and I also have a blinking cursor.  But see below.

> 
> 2. Is popup_get_selection used, the way you compiled Emacs?

I tried it both ways, i.e. Emacs compiled with Lucid/Motif and GTK/no toolkit.

The reason no timers are actualy run is this code in alarm_signal_handler in 
atimer.c:
   while (atimers
	 && (pending_atimers = interrupt_input_blocked) == 0
	 && EMACS_TIME_LE (atimers->expiration, now))
   ...

Since popups are within BLOCK/UNBLOCK__INPUT, the signal handler just 
reschedules the alarm without running any timer code.


> 
> 3. Can you debug the crash that does happen?  I think anything that
> causes a crash with this patch has the potential to cause crashes
> occasionally even without this patch.

It is because of this code in update_tool_bar, xdisp.c:

	  /* Build desired tool-bar items from keymaps.  */
           BLOCK_INPUT;
	  f->tool_bar_items
	    = tool_bar_items (f->tool_bar_items, &f->n_tool_bar_items);
           UNBLOCK_INPUT;

The BLOCK/UNBLOCK_INPUT is needed for the GTK version.  This was discussed here
http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00155.html

The solution proposed was to do as the menu code does, first build the 
structures from Lisp code, then update the GUI.  Only the second stage needs to 
block input.  Unfortunately this has not been done yet (on my todo list).

	Jan D.

Re: alarm_signal_handler is called too frequently

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 28 Oct 2004 20:02:13 +0200, "Jan D." <jan.h.d@swipnet.se> said:

> Timers are running (scheduled), The version that uses Xt has a timer
> that runs every 0.1 seconds, and I also have a blinking cursor.

There may be some confusion between two kinds of timers: the OS-level
alarm timer and the Emacs-level (cooperative?) timer.  The timer for
Xt timeout events is the former, and the cursor blinking uses the
latter.  The function timer_check is also for the latter.

> The reason no timers are actualy run is this code in
> alarm_signal_handler in atimer.c:
>
>   while (atimers
>	 && (pending_atimers = interrupt_input_blocked) == 0
>	 && EMACS_TIME_LE (atimers->expiration, now))
>   ...
>

The above code is about the OS-level timer, which I was concerning
about in my original message.

> Since popups are within BLOCK/UNBLOCK__INPUT, the signal handler
> just reschedules the alarm without running any timer code.

Actually, the signal handler only sets the interval timer value
(set_alarm) without calling schedule_atimer in this situation.  The
new interval may become a small value, 1msec, by the following code in
set_alarm.

      /* Don't set the interval to 0; this disables the timer.  */
      if (EMACS_TIME_LE (atimers->expiration, now))
	{
	  EMACS_SET_SECS (time, 0);
	  EMACS_SET_USECS (time, 1000);
	}

      bzero (&it, sizeof it);
      it.it_value = time;
      setitimer (ITIMER_REAL, &it, 0);

That's the reason why I did the following question:

  I think we don't have to call set_alarm when pending_atimers is
  non-zero because do_pending_atimers is supposed to be called
  eventually in such a case.  Is that correct?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: alarm_signal_handler is called too frequently

[Jan D.]

YAMAMOTO Mitsuharu wrote:

> There may be some confusion between two kinds of timers: the OS-level
> alarm timer and the Emacs-level (cooperative?) timer.  The timer for
> Xt timeout events is the former, and the cursor blinking uses the
> latter.  The function timer_check is also for the latter.

Sorry, I misunderstood.  The timer_check is not run from popup_get_selection 
for popup menus because the argument do_timers is 0:

       if (do_timers && !XtAppPending (Xt_app_con))
         timer_check (1);

But for dialogs, do_timer is 1, so timers do get checked when a dialog is 
popped up.  However, idle timers are disabled because the event that popups the 
dialog makes Emacs non-idle.  But non-idle timers are run.  The check for 
INPUT_BLOCKED_P proposed by Richard in Feval does detect this:

   if (handling_signal || INPUT_BLOCKED_P)
     abort ();

I guess we just have to get rid of the call to timer_check in popup_get_selection.

> 
>>Since popups are within BLOCK/UNBLOCK__INPUT, the signal handler
>>just reschedules the alarm without running any timer code.
> 
> 
> Actually, the signal handler only sets the interval timer value
> (set_alarm) without calling schedule_atimer in this situation.  The
> new interval may become a small value, 1msec, by the following code in
> set_alarm.
> 
>       /* Don't set the interval to 0; this disables the timer.  */
>       if (EMACS_TIME_LE (atimers->expiration, now))
> 	{
> 	  EMACS_SET_SECS (time, 0);
> 	  EMACS_SET_USECS (time, 1000);
> 	}
> 
>       bzero (&it, sizeof it);
>       it.it_value = time;
>       setitimer (ITIMER_REAL, &it, 0);

By "reschedules the alarm" I meant that the code arranges for another SIGALRM 
to be delivered.  And yes, the time is 1 millisecond.

> 
> That's the reason why I did the following question:
> 
>   I think we don't have to call set_alarm when pending_atimers is
>   non-zero because do_pending_atimers is supposed to be called
>   eventually in such a case.  Is that correct?

You mean like this?

Index: atimer.c
*** atimer.c.~1.16.~    2004-07-19 12:53:25.000000000 +0200
--- atimer.c    2004-10-29 08:56:37.000000000 +0200
***************
*** 397,402 ****
--- 397,403 ----
         EMACS_GET_TIME (now);
       }

+   if (! (pending_atimers && interrupt_input_blocked))
       set_alarm ();
   }


That works and should save a couple of CPU cycles.

	Jan D.

Re: alarm_signal_handler is called too frequently

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 29 Oct 2004 09:00:14 +0200, "Jan D." <jan.h.d@swipnet.se> said:

>> That's the reason why I did the following question:
>> 
>>   I think we don't have to call set_alarm when pending_atimers is
>>   non-zero because do_pending_atimers is supposed to be called
>>   eventually in such a case.  Is that correct?

> You mean like this?

> +   if (! (pending_atimers && interrupt_input_blocked))
>        set_alarm ();

> That works and should save a couple of CPU cycles.

I've been using the similar patch in

  http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg00553.html

for two weeks on Solaris/X11 and Mac OS X/Carbon, and it seems to work
fine for me.

Reduction of CPU cycles is prominent in Mac OS X/Carbon where
BLOCK_INPUT is enabled for a long time while waiting for some user
input in sys_select (mac.c).  We need BLOCK_INPUT (or something like
this) here because the only way to know whether input is available or
not is to call ReceiveNextEvent, and this function is not reentrant.
I think we don't have to poll input with signal while waiting for
input.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

    The BLOCK/UNBLOCK_INPUT is needed for the GTK version.  This was discussed here
    http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00155.html

    The solution proposed was to do as the menu code does, first build the 
    structures from Lisp code, then update the GUI.  Only the second stage needs to 
    block input.  Unfortunately this has not been done yet (on my todo list).

So the cause is a real bug, albeit not one unknown.

When do you think you'll be able to do make this change?
We need it before the release.  (I will add it to FOR-RELEASE.)

Re: alarm_signal_handler is called too frequently

[Jan D.]

Richard Stallman wrote:
>     The BLOCK/UNBLOCK_INPUT is needed for the GTK version.  This was discussed here
>     http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00155.html
> 
>     The solution proposed was to do as the menu code does, first build the 
>     structures from Lisp code, then update the GUI.  Only the second stage needs to 
>     block input.  Unfortunately this has not been done yet (on my todo list).
> 
> So the cause is a real bug, albeit not one unknown.
> 
> When do you think you'll be able to do make this change?
> We need it before the release.  (I will add it to FOR-RELEASE.)

I've checked in the change.

	Jan D.

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

    Sorry, I misunderstood.  The timer_check is not run from popup_get_selection 
    for popup menus because the argument do_timers is 0:

	   if (do_timers && !XtAppPending (Xt_app_con))
	     timer_check (1);

    But for dialogs, do_timer is 1, so timers do get checked when a dialog is 
    popped up.

Can anyone figure out why these two cases uses different values for
do_timer?  They also use different values for down_on_keypress.
cthose arguments are clearly there so that the two callers could treat
these differently.  There must have been a reason.

    I guess we just have to get rid of the call to timer_check in
    popup_get_selection.

I guess we do.  Will this mean that the cursor doesn't blink?
If so, it would be good to make sure that the cursor is ON
rather than off.

Re: alarm_signal_handler is called too frequently

[Jan D.]

Richard Stallman wrote:
>     Sorry, I misunderstood.  The timer_check is not run from popup_get_selection 
>     for popup menus because the argument do_timers is 0:
> 
> 	   if (do_timers && !XtAppPending (Xt_app_con))
> 	     timer_check (1);
> 
>     But for dialogs, do_timer is 1, so timers do get checked when a dialog is 
>     popped up.
> 
> Can anyone figure out why these two cases uses different values for
> do_timer?  They also use different values for down_on_keypress.
> cthose arguments are clearly there so that the two callers could treat
> these differently.  There must have been a reason.

I can't say why the do_timer argument is different, the modification was made 
by you almost 2 years ago:
2002-12-21  Richard M. Stallman  <rms@gnu.org>

	* xmenu.c (popup_get_selection): Now static.  New arg DO_TIMERS.
	If it is non-nil, run timers.  Use an unwind-protect to requeue
	the events that were read ahead.
	(popup_get_selection_unwind): New subroutine.
	(popup_get_selection_queue): File-scope variable now holds that queue.
	(xmenu_show): Pass 0 for DO_TIMERS to popup_get_selection.
	(xdialog_show): Pass 1 for DO_TIMERS to popup_get_selection.
	Use an unwind-protect to pop down the dialog box.
	(xdialog_show_unwind): New subroutine implements that.

I can speculate that since popup menus does a grab and dialog does not, there 
might have been some difference in event handling.

The reason for the difference in down_on_keypress is that when a popup menu is 
up, the keyboard is grabbed, so no keypresses goes to the Emacs frame anyway. 
But for a dialog there might be events that goes to the Emacs frame (for 
example if you have focus-follows-mouse and the focus is not on the dialog, but 
on the frame).  For such events the dialog is popped down (as per the old 
behaviour from previous Emacs versions).

> 
>     I guess we just have to get rid of the call to timer_check in
>     popup_get_selection.
> 
> I guess we do.  Will this mean that the cursor doesn't blink?
> If so, it would be good to make sure that the cursor is ON
> rather than off.

Yes, it means that the cursor does not blink for popup menus or dialogs.  This 
is the same as for Emacs 21.2 (the oldest I have here).  The difference is that 
  in CVS Emacs the cursor turns hollow when a dialog or menu is popped up, 
previously it stayed solid.

	Jan D.

Re: alarm_signal_handler is called too frequently

[Jan D.]

> The reason for the difference in down_on_keypress is that when a popup 
> menu is up, the keyboard is grabbed, so no keypresses goes to the 
> Emacs frame anyway.

... and most importantly, you can navigate a popup menu (Lucid) with 
arrow keys (now that I fixed a bug that crashed Emacs).  We don't want 
the arrow keys to pop the menu down.  ESC can be used to pop the menu 
down.

	Jan D.

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

    I can't say why the do_timer argument is different, the modification was made 
    by you almost 2 years ago:

Judging by the date when I made the change, I was probably looking at
bug reports saved up from the previous months.  I didn't mail the
patch to anyone at the time.

Perhaps it has to do with y-or-n-p-with-timeout.
Can that operate with a dialog?  If so, it now won't work
correctly; the timeout will be ignored.  We could make
the timeout work once again using some other mechanism,
I guess.

Re: alarm_signal_handler is called too frequently

[Jan D.]

Richard Stallman wrote:
>     I can't say why the do_timer argument is different, the modification was made 
>     by you almost 2 years ago:
> 
> Judging by the date when I made the change, I was probably looking at
> bug reports saved up from the previous months.  I didn't mail the
> patch to anyone at the time.
> 
> Perhaps it has to do with y-or-n-p-with-timeout.
> Can that operate with a dialog?  If so, it now won't work
> correctly; the timeout will be ignored.  We could make
> the timeout work once again using some other mechanism,
> I guess.

y-or-n-p-with-timeout will pop up a dialog when invoked with the mouse (i.e. 
tool or menu bar).  And yes, it will not time out.  It never did for GTK or Mac 
OSX BTW, as they do not process timers if a dialog is popped up.

Currently there are no such menu or tool bar entries, but I guess other 
packages may add such an item.

But I was wondering if the differences in how dialogs and menus are invoked may 
make a difference.  A menu is invoked as a result of a KeyPress, which arrives 
in the signal handler.  But a dialog is always popped up by lisp code, not 
directly from the signal handler.  Does this matter?


	Jan D.

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

    y-or-n-p-with-timeout will pop up a dialog when invoked with the
    mouse (i.e.  tool or menu bar).  And yes, it will not time out.
    It never did for GTK or Mac OSX BTW, as they do not process timers
    if a dialog is popped up.

    Currently there are no such menu or tool bar entries, but I guess
    other packages may add such an item.

I think we either should implement y-or-n-p-with-timeout correctly or
give up on doing so.  If we give up, we should mark it obsolete now.

Which do people think we should do?

    But I was wondering if the differences in how dialogs and menus
    are invoked may make a difference.  A menu is invoked as a result
    of a KeyPress, which arrives in the signal handler.

Are you thinking of the menu bar?  I think this code is concerned only
with popup menus; they are invoked with x-popup-menu, which is
analogous to x-popup-dialog.  So it has nothing to do with KeyPress.

Re: alarm_signal_handler is called too frequently

[Jan D.]

> Are you thinking of the menu bar?  I think this code is concerned only
> with popup menus; they are invoked with x-popup-menu, which is
> analogous to x-popup-dialog.  So it has nothing to do with KeyPress.

Duh, I meant ButtonPress.  Anyway, both popup menus and dialogs are 
equal in this regard.

	Jan D.

Re: alarm_signal_handler is called too frequently

[Jan D.]

Richard Stallman wrote:
>     I can't say why the do_timer argument is different, the modification was made 
>     by you almost 2 years ago:
> 
> Judging by the date when I made the change, I was probably looking at
> bug reports saved up from the previous months.  I didn't mail the
> patch to anyone at the time.
> 
> Perhaps it has to do with y-or-n-p-with-timeout.
> Can that operate with a dialog?  If so, it now won't work
> correctly; the timeout will be ignored.  We could make
> the timeout work once again using some other mechanism,
> I guess.

I think that is the case, there was a bug report on bug-gnu-emacs about it 4 
days before the checkin,
http://lists.gnu.org/archive/html/bug-gnu-emacs/2002-12/msg00062.html:

> From: 	Järneström Jonas
> Subject: 	y-or-n-p-with-timeout fails when using dialog box input
> Date: 	Mon, 16 Dec 2002 18:31:35 +0100 (MET)
> 
> In GNU Emacs 20.7.1 (sparc-sun-solaris2.8, X toolkit)
>  of Tue Jan 16 2001 on sunray8.era-a.ericsson.se
> configured using `configure  --prefix=/usr/bag/emacs/20.7 
> --datadir=/usr/bag/emacs/share'
> 
> See the funs below. 
> When I run the first one, timeout never happens.
> When I run the second one, timeout works ok.
> Why dont I get the timeout when using the dialog box input method?
> 
> Thanks,
> Jonas Jarnestrom
> 
> (defun dialog-box-timeout-never-happens ()
>   (let* ((last-nonmenu-event nil))
>     (y-or-n-p-with-timeout "prompt" 3 'timeout)))
> 
> (defun minibuffer-timeout-works ()
>   (let* ((foo nil))
>     (y-or-n-p-with-timeout "prompt" 3 'timeout)))

	Jan D.

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

    > Are you thinking of the menu bar?  I think this code is concerned only
    > with popup menus; they are invoked with x-popup-menu, which is
    > analogous to x-popup-dialog.  So it has nothing to do with KeyPress.

    Duh, I meant ButtonPress.  Anyway, both popup menus and dialogs are 
    equal in this regard.

Yes, but I think neither of them is invoked with ButtonPress.
They are called by Lisp and from read_char_x_menu_prompt.

Re: alarm_signal_handler is called too frequently

[Jan D.]

I made my question very unclear, I'll try again.  Sorry if this is 
obvious for others, but I just don't understand.

Say we have three functions, aL, bL and cL, all written in Lisp (hence 
the L).  Now, obviously aL calling bL calling cL is safe (<-- denotes 
return, not cL calls bL).

1:

   aL    bL    cL
   | --> |     |
   |     | --> |
   |     | <-- |
   | <-- |     |

If we replace bL with code in C instead, is this safe?

2:

   aL    bC    cL
   | --> |     |
   |     | --> |
   |     | <-- |
   | <-- |     |

I think it must be, there are places in Emacs where C code calls Lisp 
functions.  Say now that bC calls cL within BLOCK/UNBLOCK_INPUT:

3:

   aL    bC    cL
   | --> |     |
   |   BLOCK   |
   |     | --> |
   |     | <-- |
   |   UNBLOCK |
   | <-- |     |

Why is this unsafe, if 2 was safe (if indeed it is)?  It is not as 
though the signal handler is calling Lisp code, that is obviously 
unsafe.  But when a dialog or popup menu is popped up, the signal 
handler is not involved in processing X events, it is all done inside 
bC.

I'm sorry if this is a stupid question, but I just don't get it.

	Jan D.

Re: alarm_signal_handler is called too frequently

[Kim F. Storm]

I don't get it either.

Why is it unsafe to Feval with input blocked?

Actually, to me it seems to be safer to do it while input is blocked!


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

> I made my question very unclear, I'll try again.  Sorry if this is
> obvious for others, but I just don't understand.
>
> Say we have three functions, aL, bL and cL, all written in Lisp (hence
> the L).  Now, obviously aL calling bL calling cL is safe (<-- denotes
> return, not cL calls bL).
>
> 1:
>
>    aL    bL    cL
>    | --> |     |
>    |     | --> |
>    |     | <-- |
>    | <-- |     |
>
> If we replace bL with code in C instead, is this safe?
>
> 2:
>
>    aL    bC    cL
>    | --> |     |
>    |     | --> |
>    |     | <-- |
>    | <-- |     |
>
> I think it must be, there are places in Emacs where C code calls Lisp
> functions.  Say now that bC calls cL within BLOCK/UNBLOCK_INPUT:
>
> 3:
>
>    aL    bC    cL
>    | --> |     |
>    |   BLOCK   |
>    |     | --> |
>    |     | <-- |
>    |   UNBLOCK |
>    | <-- |     |
>
> Why is this unsafe, if 2 was safe (if indeed it is)?  It is not as
> though the signal handler is calling Lisp code, that is obviously
> unsafe.  But when a dialog or popup menu is popped up, the signal
> handler is not involved in processing X events, it is all done inside
> bC.
>
> I'm sorry if this is a stupid question, but I just don't get it.
>
> 	Jan D.
>

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: alarm_signal_handler is called too frequently

[Richard Stallman]

    Why is it unsafe to Feval with input blocked?

I thought that this was not handled at all, and wouldn't have a chance
of working right.  But I can't find a reason now why it won't work.