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

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

[Barry OReilly]

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

The patch addresses:

> If it means to block SIGALRM during timers, that doesn't always
> happen because timers run within timers. The end of an inner timer
> would unblock SIGALRM and the outer timer would finish with the
> sigmask unblocked.

but I don't see it address:

> But what happens if the next timer happens to be soon, and Emacs
> receives SIGALRM inbetween set_alarm and unblock_timers?

That one sounds more likely to cause a timer to stop.

[-- Attachment #2: Type: text/html, Size: 613 bytes --]

bug#15561: periodic timer stops running

[Paul Eggert]

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

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

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

[Eli Zaretskii]

> Date: Fri, 28 Feb 2014 12:03:09 +0400
> From: Dmitry Antipov <antipov@dev.rtsoft.ru>
> Cc: 15561@debbugs.gnu.org
> 
> BTW, we have at least one backtrace with nested calls to timer_check_2 (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16817#11):

Perhaps we should bind Vtimer_list to nil when we call Lisp in
timer_check_2.

But in general, timer_check_2 works on a copy of Vtimer_list, so
calling it recursively is not necessarily a problem, I think.  Do you
see any potential problems?

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

[Stefan Monnier]

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

That can clearly happen if a timer does things like sit-for.

> Perhaps we should bind Vtimer_list to nil when we call Lisp in
> timer_check_2.

No, because a timer may also want to schedule a new timer or cancel an
old one.


        Stefan