Broken timers (handle_alarm_signal is never called)?

Broken timers (handle_alarm_signal is never called)?

[Dmitry Antipov]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

Can someone explain when handle_alarm_signal is expected to be called?

Executing keyboard macro, say, 100000 times, should enter Emacs into "busy"
state.  Thus hourglass cursor should be displayed, which is done with 1s
delay via start_atimer.  This means that SIGARLM should be (re)scheduled,
and it is.  But handle_alarm_signal is never called; instead, timers are
processed just after the next input becomes available.  So if there is no
input, timers will be processed...never?  If yes, this looks like a very
strange (read: fundamentally broken) timers subsystem.

It should be not so hard to observe this scenario under gdb or with attached
tracing patch.

Dmitry






[-- Attachment #2: timer-trace.patch --]
[-- Type: text/x-patch, Size: 896 bytes --]

=== modified file 'src/atimer.c'
--- src/atimer.c	2014-05-30 04:12:08 +0000
+++ src/atimer.c	2014-07-25 13:53:31 +0000
@@ -292,7 +292,13 @@
 	  ispec.it_value = atimers->expiration;
 	  ispec.it_interval.tv_sec = ispec.it_interval.tv_nsec = 0;
 	  if (timer_settime (alarm_timer, 0, &ispec, 0) == 0)
-	    return;
+	    {
+	      fprintf (stderr, "%f: schedule alarm at %ld:%ld\n",
+		       timespectod (current_timespec ()),
+		       atimers->expiration.tv_sec,
+		       atimers->expiration.tv_nsec);
+	      return;
+	    }
 	}
 #endif
 
@@ -370,6 +376,7 @@
 static void
 handle_alarm_signal (int sig)
 {
+  fprintf (stderr, "%f: got %d\n", timespectod (current_timespec ()), sig);
   pending_signals = 1;
 }
 
@@ -379,6 +386,7 @@
 void
 do_pending_atimers (void)
 {
+  fprintf (stderr, "%f: run timers\n", timespectod (current_timespec ()));
   if (atimers)
     {
       sigset_t oldset;

Re: Broken timers (handle_alarm_signal is never called)?

[Eli Zaretskii]

> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: Paul Eggert <eggert@cs.ucla.edu>
> 
> handle_alarm_signal is never called; instead, timers are processed
> just after the next input becomes available.

How did you deduce that?

Are you saying that SIGARLM is triggered, but its handler is never
called?

Re: Broken timers (handle_alarm_signal is never called)?

[Eli Zaretskii]

> Date: Fri, 25 Jul 2014 17:28:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> > From: Dmitry Antipov <dmantipov@yandex.ru>
> > Cc: Paul Eggert <eggert@cs.ucla.edu>
> > 
> > handle_alarm_signal is never called; instead, timers are processed
> > just after the next input becomes available.
> 
> How did you deduce that?

Btw, we don't call start_hourglass when a keyboard macro is being
executed, which might explain part of your observations (but then I'd
expect not to see SIGARLMs at all).

Re: Broken timers (handle_alarm_signal is never called)?

[Dmitry Antipov]

On 07/25/2014 06:28 PM, Eli Zaretskii wrote:

> How did you deduce that?

I'm trying to change mouse cursor shape when Emacs is idle for some
period of time and now diving somewhere in main event loop in attempt
to understand what "idle" really is :-).

> Are you saying that SIGARLM is triggered, but its handler is never
> called?

No, there is no SIGALRM at all (at least I can't see it in gdb with
'handle SIGALRM print').

[...from another e-mail...]

 > Btw, we don't call start_hourglass when a keyboard macro is being executed

IIUC we do it immediately before starting macro.

Dmitry

Re: Broken timers (handle_alarm_signal is never called)?

[Eli Zaretskii]

> Date: Fri, 25 Jul 2014 19:28:52 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
>  > Btw, we don't call start_hourglass when a keyboard macro is being executed
> 
> IIUC we do it immediately before starting macro.

I just tried to interpret this code from keyboard.c:

  #ifdef HAVE_WINDOW_SYSTEM
	      ptrdiff_t scount = SPECPDL_INDEX ();

	      if (display_hourglass_p
		  && NILP (Vexecuting_kbd_macro))
		{    ^^^^^^^^^^^^^^^^^^^^^^^^^^
		  record_unwind_protect_void (cancel_hourglass);
		  start_hourglass ();
		}
  #endif

Re: Broken timers (handle_alarm_signal is never called)?

[Paul Eggert]

On 07/25/2014 09:59 AM, Dmitry Antipov wrote:
> Can someone explain when handle_alarm_signal is expected to be called? 

It's supposed to be called every time SIGALRM is delivered.  I expect 
this isn't really answering your underlying question, and I'm afraid I 
did not really follow the question.  But have you fixed the problem 
(whatever it was) already, in trunk bzr 117574?

Re: Broken timers (handle_alarm_signal is never called)?

[Dmitry Antipov]

On 07/26/2014 01:54 AM, Paul Eggert wrote:

> It's supposed to be called every time SIGALRM is delivered.  I expect this
> isn't really answering your underlying question, and I'm afraid I did not
> really follow the question.  But have you fixed the
> problem (whatever it was) already, in trunk bzr 117574?

Yes.  The question was "where is my SIGARLM from POSIX interval timer?"
Since atimer expiration is absolute, we should arm the system timer using
absolute time (with TIMER_ABSTIME) but not relative (which is by default).

Dmitry