From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.help Subject: Re: Repeating timers and suspending the computer Date: Tue, 13 Dec 2022 06:16:53 +0100 Message-ID: <87zgbrdgsa.fsf@mbork.pl> References: <87r0x9dug9.fsf@mbork.pl> <834ju511jl.fsf@gnu.org> <87ilijdjls.fsf@mbork.pl> <83pmcqv3dm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34307"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.1.0; emacs 29.0.50 Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 13 06:17:51 2022 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p4xfr-0008iT-Js for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 13 Dec 2022 06:17:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4xfC-0000bA-VW; Tue, 13 Dec 2022 00:17:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4xfA-0000aq-68 for help-gnu-emacs@gnu.org; Tue, 13 Dec 2022 00:17:08 -0500 Original-Received: from mail.mojserwer.eu ([195.110.48.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4xf7-0006Kg-RO; Tue, 13 Dec 2022 00:17:07 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 443BC7EF66C; Tue, 13 Dec 2022 06:17:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Original-Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CFWQjDcpsRR; Tue, 13 Dec 2022 06:16:56 +0100 (CET) Original-Received: from localhost (178235147188.dynamic-3-poz-k-0-1-0.vectranet.pl [178.235.147.188]) by mail.mojserwer.eu (Postfix) with ESMTPSA id BB6A12271589; Tue, 13 Dec 2022 06:16:55 +0100 (CET) In-reply-to: <83pmcqv3dm.fsf@gnu.org> Received-SPF: pass client-ip=195.110.48.8; envelope-from=mbork@mbork.pl; helo=mail.mojserwer.eu X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:141694 Archived-At: On 2022-12-11, at 07:52, Eli Zaretskii wrote: >> From: Marcin Borkowski >> Cc: help-gnu-emacs@gnu.org >> Date: Sat, 10 Dec 2022 22:39:11 +0100 >> >> >> Frankly, I expected my function to be called either once or 10 times, >> but not twice. >> >> So, how can I get a better mental model? > > By looking at the source, of course. There you will see that if the > expected number of calls exceeds the limit, Emacs advances the "last > invocation time" of the timer to the current time, thus effectively > bypassing all those delayed invocations. Well, I looked at timer.el, but it seems (not surprisingly) that timers are implemented at least partially in the C core: --8<---------------cut here---------------start------------->8--- (defun timer-event-handler (timer) "Call the handler for the timer TIMER. This function is called, by name, directly by the C code." ... ) --8<---------------cut here---------------end--------------->8--- and I'm not brave nor knowledgeable enough to dive there. But here is one part I found: --8<---------------cut here---------------start------------->8--- ;; If real time has jumped forward, ;; perhaps because Emacs was suspended for a long time, ;; limit how many times things get repeated. (if (and (numberp timer-max-repeats) (time-less-p (timer--time timer) nil)) (let ((repeats (/ (timer-until timer nil) (timer--repeat-delay timer)))) (if (> repeats timer-max-repeats) (timer-inc-time timer (* (timer--repeat-delay timer) repeats))))) --8<---------------cut here---------------end--------------->8--- Do I get it correctly that this means that of the scheduled number of repeats is /less/ than `timer-max-repeats', then all of them get executed, but when it is greater than that, only one of them is? Here is the declaration of that variable: --8<---------------cut here---------------start------------->8--- (defcustom timer-max-repeats 10 "Maximum number of times to repeat a timer, if many repeats are delayed. Timer invocations can be delayed because Emacs is suspended or busy, or because the system's time changes. If such an occurrence makes it appear that many invocations are overdue, this variable controls how many will really happen." :type 'integer :group 'internal) --8<---------------cut here---------------end--------------->8--- Now I can see that the docstring is ambiguous, isn't it? What it seems to do is "if the timer-ed function would be called more than `timer-max-repeats' times, run it just once", and what I understood from the docstring was "if the timer-ed function would be called more than `timer-max-repeats' times, run it `timer-max-repeats' times". > Why you see 2 calls instead of just the expected one needs more > investigation. At the very least, it depends on the exact time when > your computer was awoken: if that time was close to the integral > multiple of the timer period, you can legitimately see two invocations > with a very small time interval between them. But maybe some other > factor is at work here. If you are really interested, I suggest to > instrument timer.el with some calls to 'message' and repeat the > experiment to learn why that happens. That is interesting. What I did was more or less this: --8<---------------cut here---------------start------------->8--- (setq testing-timer (run-with-timer 1 1 (lambda () (message "%s" (format-time-string "%H:%M:%S.%3N"))))) --8<---------------cut here---------------end--------------->8--- so that I knew the exact time my function was run, and it seems that if I waited much longer than 10 seconds, it was run twice at the exact same moment. I'm not sure if I'm determined enough to investigate this further... Thank you very much, now I know much more about timers! -- Marcin Borkowski http://mbork.pl