all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Broken timers (handle_alarm_signal is never called)?
@ 2014-07-25 13:59 Dmitry Antipov
  2014-07-25 14:28 ` Eli Zaretskii
  2014-07-25 21:54 ` Paul Eggert
  0 siblings, 2 replies; 7+ messages in thread
From: Dmitry Antipov @ 2014-07-25 13:59 UTC (permalink / raw)
  To: Emacs development discussions; +Cc: Paul Eggert

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Broken timers (handle_alarm_signal is never called)?
  2014-07-25 13:59 Broken timers (handle_alarm_signal is never called)? Dmitry Antipov
@ 2014-07-25 14:28 ` Eli Zaretskii
  2014-07-25 14:43   ` Eli Zaretskii
  2014-07-25 15:28   ` Dmitry Antipov
  2014-07-25 21:54 ` Paul Eggert
  1 sibling, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2014-07-25 14:28 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: eggert, emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Broken timers (handle_alarm_signal is never called)?
  2014-07-25 14:28 ` Eli Zaretskii
@ 2014-07-25 14:43   ` Eli Zaretskii
  2014-07-25 15:28   ` Dmitry Antipov
  1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2014-07-25 14:43 UTC (permalink / raw)
  To: dmantipov; +Cc: eggert, emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Broken timers (handle_alarm_signal is never called)?
  2014-07-25 14:28 ` Eli Zaretskii
  2014-07-25 14:43   ` Eli Zaretskii
@ 2014-07-25 15:28   ` Dmitry Antipov
  2014-07-25 18:48     ` Eli Zaretskii
  1 sibling, 1 reply; 7+ messages in thread
From: Dmitry Antipov @ 2014-07-25 15:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: eggert, emacs-devel

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Broken timers (handle_alarm_signal is never called)?
  2014-07-25 15:28   ` Dmitry Antipov
@ 2014-07-25 18:48     ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2014-07-25 18:48 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: eggert, emacs-devel

> 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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Broken timers (handle_alarm_signal is never called)?
  2014-07-25 13:59 Broken timers (handle_alarm_signal is never called)? Dmitry Antipov
  2014-07-25 14:28 ` Eli Zaretskii
@ 2014-07-25 21:54 ` Paul Eggert
  2014-07-26  3:42   ` Dmitry Antipov
  1 sibling, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2014-07-25 21:54 UTC (permalink / raw)
  To: Dmitry Antipov, Emacs development discussions

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?



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Broken timers (handle_alarm_signal is never called)?
  2014-07-25 21:54 ` Paul Eggert
@ 2014-07-26  3:42   ` Dmitry Antipov
  0 siblings, 0 replies; 7+ messages in thread
From: Dmitry Antipov @ 2014-07-26  3:42 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Emacs development discussions

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-07-26  3:42 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-25 13:59 Broken timers (handle_alarm_signal is never called)? Dmitry Antipov
2014-07-25 14:28 ` Eli Zaretskii
2014-07-25 14:43   ` Eli Zaretskii
2014-07-25 15:28   ` Dmitry Antipov
2014-07-25 18:48     ` Eli Zaretskii
2014-07-25 21:54 ` Paul Eggert
2014-07-26  3:42   ` Dmitry Antipov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.