From unknown Sun Jun 15 08:26:43 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#35400 <35400@debbugs.gnu.org> To: bug#35400 <35400@debbugs.gnu.org> Subject: Status: 27.0.50; Timers repeated after waking from suspend Reply-To: bug#35400 <35400@debbugs.gnu.org> Date: Sun, 15 Jun 2025 15:26:43 +0000 retitle 35400 27.0.50; Timers repeated after waking from suspend reassign 35400 emacs submitter 35400 Stefan Monnier severity 35400 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 23 12:59:55 2019 Received: (at submit) by debbugs.gnu.org; 23 Apr 2019 16:59:55 +0000 Received: from localhost ([127.0.0.1]:54222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hIylu-0004El-Se for submit@debbugs.gnu.org; Tue, 23 Apr 2019 12:59:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42029) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hIyls-0004EX-Ix for submit@debbugs.gnu.org; Tue, 23 Apr 2019 12:59:53 -0400 Received: from lists.gnu.org ([209.51.188.17]:58990) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hIyln-00068G-75 for submit@debbugs.gnu.org; Tue, 23 Apr 2019 12:59:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIylm-0007h7-3I for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2019 12:59:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIyll-000652-32 for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2019 12:59:46 -0400 Received: from alt24.smtp-out.videotron.ca ([70.80.0.75]:34380) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hIylk-000632-SY for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2019 12:59:44 -0400 Received: from fmsmemgm.homelinux.net ([24.203.163.157]) by Videotron with SMTP id Iylihzs1RHTT3IyljhWyX9; Tue, 23 Apr 2019 12:59:44 -0400 X-Authority-Analysis: v=2.3 cv=ZegzyPdA c=1 sm=1 tr=0 a=271BjrAMcq2W4n6OKK/JJg==:117 a=271BjrAMcq2W4n6OKK/JJg==:17 a=oexKYjalfGEA:10 a=aR16PxjQAAAA:8 a=RB2lgiZKs_l3Kn8TLNgA:9 a=zbFvvTOBjyH4ze5LlUjX:22 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id B0A13AE1E3; Tue, 23 Apr 2019 12:59:42 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 27.0.50; Timers repeated after waking from suspend Date: Tue, 23 Apr 2019 12:59:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-CMAE-Envelope: MS4wfJGRgS4IbwoLWABKl33iYeZSzs16Ear0UrPGvMxx6DpbbUFenWaJEfu+LAGkMpDJ4PaQQKJl73PYHmESZLKDtO+GA0MQDZueIJ+h/W9nvDcB1fIA6OaS 5SewftEZzSvxRNJJJpUcCC2Z+WlDg/07zbFwV6Cis6WXtYaRu00HpHCNP5bEhcbQA/Meu6nM+CiTqg== X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 70.80.0.75 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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 now wait a minute and then kill -CONT 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) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 23 13:30:44 2019 Received: (at 35400) by debbugs.gnu.org; 23 Apr 2019 17:30:45 +0000 Received: from localhost ([127.0.0.1]:54267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hIzFk-0004yy-Hz for submit@debbugs.gnu.org; Tue, 23 Apr 2019 13:30:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hIzFj-0004yn-Hp for 35400@debbugs.gnu.org; Tue, 23 Apr 2019 13:30:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIzFa-0004Bu-5i; Tue, 23 Apr 2019 13:30:36 -0400 Received: from [176.228.60.248] (port=4411 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hIzFU-0004G3-QH; Tue, 23 Apr 2019 13:30:30 -0400 Date: Tue, 23 Apr 2019 20:30:19 +0300 Message-Id: <834l6o4ok4.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Tue, 23 Apr 2019 12:59:42 -0400) Subject: Re: bug#35400: 27.0.50; Timers repeated after waking from suspend References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35400 Cc: 35400@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Date: Tue, 23 Apr 2019 12:59:42 -0400 > > now wait a minute and then > > kill -CONT > > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 02 09:34:24 2021 Received: (at 35400) by debbugs.gnu.org; 2 Feb 2021 14:34:25 +0000 Received: from localhost ([127.0.0.1]:34408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l6wl6-0008V4-MC for submit@debbugs.gnu.org; Tue, 02 Feb 2021 09:34:24 -0500 Received: from quimby.gnus.org ([95.216.78.240]:33314) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l6wl4-0008Uq-GH for 35400@debbugs.gnu.org; Tue, 02 Feb 2021 09:34:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sKXGiLMJvYn693NCIlCf9ywHRQiFgrvZ/JSCXRhyIjI=; b=fZNn7mcPeE2Yk0BWWkk5NIvNa4 nKbnVPSTSdRUFNq5kkgHLCWjk5X6idsMziT77vvMurbj0jzxcq+VI32Eh1OJaiEs9V/RCIJlFYPbR wKfO0zucY0PsKnCatIFL75Kc7Ha56+nk9uQ01Q0/JIqPscS1oh+siYNBGc6tUy2G7/Uo=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l6wku-0005Co-AS; Tue, 02 Feb 2021 15:34:15 +0100 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#35400: 27.0.50; Timers repeated after waking from suspend References: <834l6o4ok4.fsf@gnu.org> X-Now-Playing: Timothy Leary*'s _Beautiful Freaks: Waving Our Flag High: When Music Was The Counterculture_: "Part II: One Final Word" Date: Tue, 02 Feb 2021 15:34:11 +0100 In-Reply-To: <834l6o4ok4.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 23 Apr 2019 20:30:19 +0300") Message-ID: <87y2g6lesc.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35400 Cc: Stefan Monnier , 35400@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 02 10:32:57 2021 Received: (at 35400) by debbugs.gnu.org; 2 Feb 2021 15:32:57 +0000 Received: from localhost ([127.0.0.1]:36009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l6xfk-0001wg-QK for submit@debbugs.gnu.org; Tue, 02 Feb 2021 10:32:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45044) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l6xfi-0001wL-Tz for 35400@debbugs.gnu.org; Tue, 02 Feb 2021 10:32:56 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48253) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6xfd-0007nn-4a; Tue, 02 Feb 2021 10:32:49 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2216 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l6xfV-0001w9-T9; Tue, 02 Feb 2021 10:32:44 -0500 Date: Tue, 02 Feb 2021 17:32:38 +0200 Message-Id: <83ft2e5vu1.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87y2g6lesc.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 02 Feb 2021 15:34:11 +0100) Subject: Re: bug#35400: 27.0.50; Timers repeated after waking from suspend References: <834l6o4ok4.fsf@gnu.org> <87y2g6lesc.fsf@gnus.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 35400 Cc: monnier@iro.umontreal.ca, 35400@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Lars Ingebrigtsen > Cc: Stefan Monnier , 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? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 02 11:18:12 2021 Received: (at 35400) by debbugs.gnu.org; 2 Feb 2021 16:18:12 +0000 Received: from localhost ([127.0.0.1]:36044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l6yNY-00034o-Ar for submit@debbugs.gnu.org; Tue, 02 Feb 2021 11:18:12 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18249) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l6yNV-00034Y-Ax for 35400@debbugs.gnu.org; Tue, 02 Feb 2021 11:18:10 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B04F54408D2; Tue, 2 Feb 2021 11:18:03 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3EEF84408BC; Tue, 2 Feb 2021 11:18:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1612282682; bh=IUZVeQKVYHocrx7fqfbbS/jMhCQJ/sWc88lNJVtbajY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=C1pEJuNmLUOds99P9IDMM1cH+bkCd3aiseRY+AcBhD+D0vRIPWV2KW5RnKCQZWmoM HC+bAaHBDoXxxqihxYdu4gtj+ArFOLM9fufw7KtICgQr2AJPYgMJZrcNxcbTzqSXOG M48PH2lfpdbDDb3W/2AFI7moWXH4WYEVL39r+QnK85jnvy95gTIKKTSLNTRzhGIqcA lvNbCTP6bgQi/b51uUqHfzXYBW2+XNoIsKa4bwBxhYKRgx4VrWzdmdQV9XBG+ihG/R NfWapgi3Kz3BGrbMkNBu8wrqRiquV2WtgmkydKE3EISygjpwJ5J0xPIbOhZrzyFI1b 0I+/IxEuX86/g== Received: from alfajor (76-10-182-85.dsl.teksavvy.com [76.10.182.85]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 038491200B8; Tue, 2 Feb 2021 11:18:01 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#35400: 27.0.50; Timers repeated after waking from suspend Message-ID: References: <834l6o4ok4.fsf@gnu.org> <87y2g6lesc.fsf@gnus.org> <83ft2e5vu1.fsf@gnu.org> Date: Tue, 02 Feb 2021 11:18:01 -0500 In-Reply-To: <83ft2e5vu1.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Feb 2021 17:32:38 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.102 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35400 Cc: Lars Ingebrigtsen , 35400@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 03 13:42:45 2021 Received: (at 35400) by debbugs.gnu.org; 3 Feb 2021 18:42:45 +0000 Received: from localhost ([127.0.0.1]:38861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7N6z-00011X-8q for submit@debbugs.gnu.org; Wed, 03 Feb 2021 13:42:45 -0500 Received: from quimby.gnus.org ([95.216.78.240]:48036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7N6x-00011K-Gz for 35400@debbugs.gnu.org; Wed, 03 Feb 2021 13:42:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Tc81IQR0MgJcdjYszETQ3ogwHosbM2VHoE2USzyNSrI=; b=eG8MtNKHOI46V+yKzQ9hZtEKXq p+E6SRFAKoffQjMce3QZpAda+WnBwPkmt6kREJD7N4w1wBG7a04kz7YG+oYP1UihM9uv+99ezzBS+ rGhGPINZTz/6CGicoUdn3kroURsJq7UMwlvsi4H1HbQBYrZ/rJVfl+sj2CvuoGHw6d18=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7N6l-0004cS-0N; Wed, 03 Feb 2021 19:42:36 +0100 From: Lars Ingebrigtsen To: Stefan Monnier Subject: Re: bug#35400: 27.0.50; Timers repeated after waking from suspend References: <834l6o4ok4.fsf@gnu.org> <87y2g6lesc.fsf@gnus.org> <83ft2e5vu1.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEUUCgpbPCihhFrp 25v///9c8SoiAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UCAxIJACxIEEgAAAGESURBVDjLzZPRmcQg CIRxKxDSwIoVRPrv7QYEk7sKzof9Nv4OyCBEWMxDVMzUltJrfZjx21gN6/vstzVcRc2Raj/gsjGo dUj6R1XHEZhdqgvg+l4rjpTA5gZtCDOXpFmshX+dPyyDeUs+vn1ZKnBzSSB+/Frm4sG9U287VMQx VxA22RUPwPKKe5TZMlQCcdBkKGtmj+Nb4cdVq0ZUcYuttQPDGGTRVLixAQShEGb7pTNChVrgDWyc YXEmD8CoZ6L0yG7HEg9f2r9Ahv9lKgXSWIQSvx/SZI5oKXkHGffrNO12sFDRqhwykWLfCg6oXzIe C2rrxBZ1xBdWKlA6epUAZLsA2/dGgW1PNsg/6QCW7gb2iLdBEYAej6uAt6wA17EA9IAMJNtRphfw C2dr+eRoCdrO3ereBZQPGJnNQZtWgxCODC6gZ0Li8fIG3Xt4P/NhQ4bXFjmeYbvWDNtRakd3S0De mJjJ7YE8M+hZ7mPOa9+D5UMfv/f3ADh4T/lr3qGg/7F+ANSeRC6Wl5FSAAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIxLTAyLTAzVDE4OjA5OjAwKzAwOjAwfdGp4AAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy MS0wMi0wM1QxODowOTowMCswMDowMAyMEVwAAAAASUVORK5CYII= X-Now-Playing: Kate Bush's _The Red Shoes_: "Constellation of the Heart" Date: Wed, 03 Feb 2021 19:42:29 +0100 In-Reply-To: (Stefan Monnier's message of "Tue, 02 Feb 2021 11:18:01 -0500") Message-ID: <87tuqtgfhm.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Monnier writes: >> So maybe this should be a property of the timer itself? Yeah, that sounds like a good idea. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35400 Cc: Eli Zaretskii , 35400@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier 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