Re: alarm_signal_handler is called too frequently

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

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