GNU bug report logs - #23929
25.0.95; Doc of run-at-time doesn't describe behaviour if system was sleeping at time

Previous Next

Package: emacs;

Reported by: nljlistbox2 <at> gmail.com (N. Jackson)

Date: Sat, 9 Jul 2016 15:31:01 UTC

Severity: minor

Found in version 25.0.95

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23929 in the body.
You can then email your comments to 23929 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#23929; Package emacs. (Sat, 09 Jul 2016 15:31:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to nljlistbox2 <at> gmail.com (N. Jackson):
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 09 Jul 2016 15:31:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: nljlistbox2 <at> gmail.com (N. Jackson)
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.95;
 Doc of run-at-time doesn't describe behaviour if system was sleeping
 at time
Date: Sat, 09 Jul 2016 12:30:42 -0300
The documentation of run-at-time -- the doc string and (info "(elisp)
Timers") -- does not say what happens if the system was sleeping when
the timer would have run.


In GNU Emacs 25.0.95.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-06-14 built on moondust
Windowing system distributor 'Fedora Project', version 11.0.11803000
System Description:	Fedora release 23 (Twenty Three)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23929; Package emacs. (Sat, 09 Jul 2016 16:57:02 GMT) Full text and rfc822 format available.

Message #8 received at 23929 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: nljlistbox2 <at> gmail.com (N. Jackson)
Cc: 23929 <at> debbugs.gnu.org
Subject: Re: bug#23929: 25.0.95;
 Doc of run-at-time doesn't describe behaviour if system was sleeping
 at time
Date: Sat, 09 Jul 2016 19:56:07 +0300
> From: nljlistbox2 <at> gmail.com (N. Jackson)
> Date: Sat, 09 Jul 2016 12:30:42 -0300
> 
> The documentation of run-at-time -- the doc string and (info "(elisp)
> Timers") -- does not say what happens if the system was sleeping when
> the timer would have run.

It also doesn't say what happens if Emacs didn't get any CPU time when
the timer would have run -- which is a more general description of the
situation you mention.

If instead

  Perform an action at time TIME.

we say

  Perform an action at or after time TIME.

will this take care of the issue you are raising?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23929; Package emacs. (Sat, 09 Jul 2016 18:59:01 GMT) Full text and rfc822 format available.

Message #11 received at 23929 <at> debbugs.gnu.org (full text, mbox):

From: nljlistbox2 <at> gmail.com (N. Jackson)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23929 <at> debbugs.gnu.org
Subject: Re: bug#23929: 25.0.95;
 Doc of run-at-time doesn't describe behaviour if system was sleeping
 at time
Date: Sat, 09 Jul 2016 15:57:49 -0300
At 19:56 +0300 on Saturday 2016-07-09, Eli Zaretskii wrote:

>> From: nljlistbox2 <at> gmail.com (N. Jackson)
>> Date: Sat, 09 Jul 2016 12:30:42 -0300
>> 
>> The documentation of run-at-time -- the doc string and (info "(elisp)
>> Timers") -- does not say what happens if the system was sleeping when
>> the timer would have run.
>
> It also doesn't say what happens if Emacs didn't get any CPU time when
> the timer would have run -- which is a more general description of the
> situation you mention.
>
> If instead
>
>   Perform an action at time TIME.
>
> we say
>
>   Perform an action at or after time TIME.
>
> will this take care of the issue you are raising?

Yes, I think it might take care of the issue.

On the other hand, perhaps it would be worth being slightly more
explicit in the documentation in the manual? Perhaps it would be
worth mentioning the general case of Emacs not getting any CPU
time when the timer would have run, as well as the specific case
of the system being suspended / sleeping.

I'm not in a good position to judge how much insight into system
internals the reader of the elisp manual is expected to have. To
me, at least, it isn't immediately obvious that the case of the
system being suspended when the timer would have run is the "same"
as the case of the system being busy elsewhere when the timer
would have run.

As a casual user of the function, I just want to know whether, if
I have a timer set to run at 6:00 AM but I don't wake up my system
until 8:00 AM, if my timer will run once my system has woken up,
or if the timer will be skipped until the next day (provided my
system is awake at 6:00 AM the next day).

I would be more reassured if I saw text along the following lines
in the manual entry (provided it is true):

    "If Emacs didn't get any CPU time when the timer would have
    run (for example if the system was busy running another
    process or if the computer was sleeping or in a suspended
    state), the timer will run (late) as soon as Emacs resumes and
    is idle."

Of course, this is already almost, but not quite, stated already
twice in the manual entry. Firstly in the second paragraph:

    "Emacs cannot run timers at any arbitrary point in a Lisp
    program; it can run them only when Emacs could accept output
    from a subprocess: namely, while waiting or inside certain
    primitive functions such as ‘sit-for’ or ‘read-event’ which
    _can_ wait. Therefore, a timer’s execution may be delayed if
    Emacs is busy. However, the time of execution is very precise
    if Emacs is idle."

But this only covers the case of Emacs being busy when the timer
would have run.

And later:

    "A repeating timer nominally ought to run every REPEAT
    seconds, but remember that any invocation of a timer can be
    late. Lateness of one repetition has no effect on the
    scheduled time of the next repetition. For instance, if Emacs
    is busy computing for long enough to cover three scheduled
    repetitions of the timer, and then starts to wait, it will
    immediately call the timer function three times in immediate
    succession (presuming no other timers trigger before or
    between them)."

But this only covers the case of repeating timers.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23929; Package emacs. (Thu, 08 Jul 2021 00:45:01 GMT) Full text and rfc822 format available.

Message #14 received at 23929 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: nljlistbox2 <at> gmail.com (N. Jackson)
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23929 <at> debbugs.gnu.org
Subject: Re: bug#23929: 25.0.95; Doc of run-at-time doesn't describe
 behaviour if system was sleeping at time
Date: Thu, 08 Jul 2021 02:44:46 +0200
nljlistbox2 <at> gmail.com (N. Jackson) writes:

> I would be more reassured if I saw text along the following lines
> in the manual entry (provided it is true):
>
>     "If Emacs didn't get any CPU time when the timer would have
>     run (for example if the system was busy running another
>     process or if the computer was sleeping or in a suspended
>     state), the timer will run (late) as soon as Emacs resumes and
>     is idle."

If I remember correctly, that is true, so I've added your text to the
manual in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 28.1, send any further explanations to 23929 <at> debbugs.gnu.org and nljlistbox2 <at> gmail.com (N. Jackson) Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 08 Jul 2021 00:46:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 05 Aug 2021 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 257 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.