bug#15561: Re: bug#15561: periodic timer stops running

[Dmitry Antipov]

On 02/28/2014 06:42 AM, Paul Eggert wrote:

> [Resending with corrected bug-report address; sorry about that.]
>
> Barry OReilly wrote:
> > But what happens if the next timer happens to be soon, and Emacs receives 
> > SIGALRM inbetween set_alarm and unblock_timers?
>
> Are you talking about a SIGALRM received during the execution of 
> do_pending_atimers, between run_timer's call to set_alarm and 
> do_pending_atimers's call to unblock_atimers?  If so, the SIGALRM should
> be held by the operating system during that period, and Emacs won't be informed 
> of the SIGALRM until unblock_atimers does its thing.  Sorry, I don't see how 
> this would cause a timer to stop.

BTW, we have at least one backtrace with nested calls to timer_check_2 
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16817#11):

...
64  Emacs                               0x00000001002067b2 Ffuncall + 1762 
(eval.c:2827)
65  Emacs                               0x00000001002070e9 call1 + 73 
(eval.c:2572)
66  Emacs                               0x000000010013d6a6 timer_check_2 + 1846 
(keyboard.c:4447)                   ;; Nested call
67  Emacs                               0x000000010013cef5 timer_check + 165 
(keyboard.c:4514)
68  Emacs                               0x0000000100139c25 readable_events + 37 
(keyboard.c:3405)
69  Emacs                               0x000000010013cdb6 get_input_pending + 
54 (keyboard.c:6794)
70  Emacs                               0x0000000100142ce4 Finput_pending_p + 
132 (keyboard.c:10449)
71  Emacs                               0x000000010020652d Ffuncall + 1117 
(eval.c:2775)
72  Emacs                               0x000000010027173a exec_byte_code + 
3866 (bytecode.c:900)
73  Emacs                               0x0000000100207b6e funcall_lambda + 
1566 (eval.c:3010)
74  Emacs                               0x00000001002067b2 Ffuncall + 1762 
(eval.c:2827)
75  Emacs                               0x000000010027173a exec_byte_code + 
3866 (bytecode.c:900)
76  Emacs                               0x0000000100207b6e funcall_lambda + 
1566 (eval.c:3010)
77  Emacs                               0x00000001002067b2 Ffuncall + 1762 
(eval.c:2827)
78  Emacs                               0x0000000100205b33 Fapply + 243 
(eval.c:2255)
79  Emacs                               0x0000000100206403 Ffuncall + 819 
(eval.c:2759)
80  Emacs                               0x000000010027173a exec_byte_code + 
3866 (bytecode.c:900)
81  Emacs                               0x000000010027080f Fbyte_code + 63 
(bytecode.c:475)
82  Emacs                               0x0000000100200e79 eval_sub + 2073 
(eval.c:2149)
83  Emacs                               0x0000000100203d84 
internal_lisp_condition_case + 772 (eval.c:1243)
84  Emacs                               0x0000000100272957 exec_byte_code + 
8503 (bytecode.c:1096)
85  Emacs                               0x0000000100207b6e funcall_lambda + 
1566 (eval.c:3010)
86  Emacs                               0x00000001002067b2 Ffuncall + 1762 
(eval.c:2827)
87  Emacs                               0x00000001002070e9 call1 + 73 
(eval.c:2572)
88  Emacs                               0x000000010013d6a6 timer_check_2 + 1846 
(keyboard.c:4447)                   ;; First call
89  Emacs                               0x000000010013cef5 timer_check + 165 
(keyboard.c:4514)
90  Emacs                               0x0000000100139c25 readable_events + 37 
(keyboard.c:3405)
91  Emacs                               0x000000010013cdb6 get_input_pending + 
54 (keyboard.c:6794)
92  Emacs                               0x00000001001382e6 
detect_input_pending_run_timers + 54 (keyboard.c:10391)
93  Emacs                               0x0000000100280963 
wait_reading_process_output + 4227 (process.c:4762)
94  Emacs                               0x00000001000087fa sit_for + 634 
(dispnew.c:5981)
...

(I just wonder whether this behaviour is acceptable).

Dmitry