* bug#35400: 27.0.50; Timers repeated after waking from suspend
@ 2019-04-23 16:59 Stefan Monnier
2019-04-23 17:30 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2019-04-23 16:59 UTC (permalink / raw)
To: 35400
Package: Emacs
Version: 27.0.50
If Emacs is prevented from running for a "long" time (via the `STOP`
signal, C-z, suspend-to-ram, thrashing, you name it), the "missed"
repetitions of timer events all get run when we wake up.
E.g. you can try the following:
% emacs -Q
(run-with-timer 5 5 (lambda () (message "Run at: %s" (format-time-string "%H:%M:%S"))))
C-j
C-x b *Messages* RET
you should see a message emitted every 5 seconds. Then do:
kill -STOP <emacs-pid>
now wait a minute and then
kill -CONT <emacs-pid>
and you should see something like:
Run at: 12:49:40 [7 times]
in the *Messages* buffer, before all the repetitions that couldn't be
run while Emacs was suspended are run when we wake up.
Apparently this is *not* a new behavior (I can reproduce it with
Debian's 26.1) although I only recently started noticing it.
If we decide to consider this a feature (I guess there can be
circumstances where it might make sense, tho I'm not sure those would
really work well with the way we handle timers), I think we should
provide some way for users of timers to indicate whether they want to
use this feature or not (and I think it makes sense to default to not
using this feature).
Stefan
In GNU Emacs 27.0.50 (build 1, x86_64-unknown-linux-gnu, GTK+ Version 3.24.5)
of 2019-04-14 built on alfajor
Repository revision: bd7668ee53b3597ee229afd83e18b6cdb6315056
Repository branch: work
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Debian GNU/Linux buster/sid
Recent messages:
Mark set
Mark activated
Mark set
Auto-saving...done
Saving file /home/monnier/src/emacs/elpa/packages/smalltalk-mode/smalltalk-mode.el...
Wrote /home/monnier/src/emacs/elpa/packages/smalltalk-mode/smalltalk-mode.el
Saving file /home/monnier/share/etc/diary...
Wrote /home/monnier/share/etc/diary
Marking diary entries...done
(New file)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35400: 27.0.50; Timers repeated after waking from suspend
2019-04-23 16:59 bug#35400: 27.0.50; Timers repeated after waking from suspend Stefan Monnier
@ 2019-04-23 17:30 ` Eli Zaretskii
2021-02-02 14:34 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2019-04-23 17:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 35400
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 23 Apr 2019 12:59:42 -0400
>
> now wait a minute and then
>
> kill -CONT <emacs-pid>
>
> and you should see something like:
>
> Run at: 12:49:40 [7 times]
>
> in the *Messages* buffer, before all the repetitions that couldn't be
> run while Emacs was suspended are run when we wake up.
>
> Apparently this is *not* a new behavior (I can reproduce it with
> Debian's 26.1) although I only recently started noticing it.
>
> If we decide to consider this a feature (I guess there can be
> circumstances where it might make sense, tho I'm not sure those would
> really work well with the way we handle timers), I think we should
> provide some way for users of timers to indicate whether they want to
> use this feature or not (and I think it makes sense to default to not
> using this feature).
I think you can already control this by customizing the value of
timer-max-repeats. It is 10 by default, so you should never see more
than 10 repetitions, no matter how long was Emacs suspended.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35400: 27.0.50; Timers repeated after waking from suspend
2019-04-23 17:30 ` Eli Zaretskii
@ 2021-02-02 14:34 ` Lars Ingebrigtsen
2021-02-02 15:32 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-02 14:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stefan Monnier, 35400
Eli Zaretskii <eliz@gnu.org> writes:
>> If we decide to consider this a feature (I guess there can be
>> circumstances where it might make sense, tho I'm not sure those would
>> really work well with the way we handle timers), I think we should
>> provide some way for users of timers to indicate whether they want to
>> use this feature or not (and I think it makes sense to default to not
>> using this feature).
>
> I think you can already control this by customizing the value of
> timer-max-repeats. It is 10 by default, so you should never see more
> than 10 repetitions, no matter how long was Emacs suspended.
Right, so the only question here is whether to change the value of that
variable (to not repeat). I think that would certainly be less
surprising, but I'm not sure whether that would break people's code or
not?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35400: 27.0.50; Timers repeated after waking from suspend
2021-02-02 14:34 ` Lars Ingebrigtsen
@ 2021-02-02 15:32 ` Eli Zaretskii
2021-02-02 16:18 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2021-02-02 15:32 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: monnier, 35400
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 35400@debbugs.gnu.org
> Date: Tue, 02 Feb 2021 15:34:11 +0100
>
> > I think you can already control this by customizing the value of
> > timer-max-repeats. It is 10 by default, so you should never see more
> > than 10 repetitions, no matter how long was Emacs suspended.
>
> Right, so the only question here is whether to change the value of that
> variable (to not repeat). I think that would certainly be less
> surprising, but I'm not sure whether that would break people's code or
> not?
There are two use cases here. One is the one we have been discussing:
when Emacs wakes from suspension, or the machine wakes from sleep.
The other is that somehow Emacs didn't get CPU to run, due to some
expensive processing on the system. It might be that people expect
timers not to try to make up for the sleep or suspension period, but
they may want them to make up for the second use case.
So maybe this should be a property of the timer itself? Or maybe the
time elapsed since the last timer invocation should be the factor upon
which to decide whether to run more than once or not?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35400: 27.0.50; Timers repeated after waking from suspend
2021-02-02 15:32 ` Eli Zaretskii
@ 2021-02-02 16:18 ` Stefan Monnier
2021-02-03 18:42 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2021-02-02 16:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 35400
> There are two use cases here. One is the one we have been discussing:
> when Emacs wakes from suspension, or the machine wakes from sleep.
> The other is that somehow Emacs didn't get CPU to run, due to some
> expensive processing on the system.
Or also that Emacs did get the CPU but used it for itself running ELisp
code without stopping.
It could even be that the code it ran was the code for an earlier
invocation of that same timer.
> So maybe this should be a property of the timer itself?
I do think so, yes, but I think to fix it right we need to take a step
back and think about what it is we really want to happen, and then see
if/how we can retrofit it into the current design.
I think for the case where we missed some timer repetitions, the best
thing we can do is not to call that timer repeatedly but instead to call
it once and pass it the number of times it has fired since the last time
we ran it (so it can then freely decide to repeat its operation N times
or not).
A related issue is that for many timers, rather than "repeat every
N seconds" we'd rather want "wait N seconds between invocations" (so if
the execution of the timer terminates M seconds after the time T it was
supposed to start running, the next execution should not be scheduled
for T+N but T+M+N).
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35400: 27.0.50; Timers repeated after waking from suspend
2021-02-02 16:18 ` Stefan Monnier
@ 2021-02-03 18:42 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-03 18:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 35400
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> So maybe this should be a property of the timer itself?
Yeah, that sounds like a good idea.
> I think for the case where we missed some timer repetitions, the best
> thing we can do is not to call that timer repeatedly but instead to call
> it once and pass it the number of times it has fired since the last time
> we ran it (so it can then freely decide to repeat its operation N times
> or not).
>
> A related issue is that for many timers, rather than "repeat every
> N seconds" we'd rather want "wait N seconds between invocations" (so if
> the execution of the timer terminates M seconds after the time T it was
> supposed to start running, the next execution should not be scheduled
> for T+N but T+M+N).
That's true. I think the current way code deals with this is to ask
Emacs to repeat once, and then the function itself computes the next
delay, and then runs `run-at-time' itself (see for instance
`image-animate-timeout').
Having `run-at-time' compute this would be an improvement -- not at
least because it would be one single timer function, and you could
inspect it from `list-timers', which you can't really do today in this
scenario (because it's a new timer on every update).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-02-03 18:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-23 16:59 bug#35400: 27.0.50; Timers repeated after waking from suspend Stefan Monnier
2019-04-23 17:30 ` Eli Zaretskii
2021-02-02 14:34 ` Lars Ingebrigtsen
2021-02-02 15:32 ` Eli Zaretskii
2021-02-02 16:18 ` Stefan Monnier
2021-02-03 18:42 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).