From: nljlistbox2@gmail.com (N. Jackson)
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23929@debbugs.gnu.org
Subject: 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 [thread overview]
Message-ID: <87poqm7i6q.fsf@moondust.awandering> (raw)
In-Reply-To: <83y45ag388.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Jul 2016 19:56:07 +0300")
At 19:56 +0300 on Saturday 2016-07-09, Eli Zaretskii wrote:
>> From: nljlistbox2@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.
next prev parent reply other threads:[~2016-07-09 18:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-09 15:30 bug#23929: 25.0.95; Doc of run-at-time doesn't describe behaviour if system was sleeping at time N. Jackson
2016-07-09 16:56 ` Eli Zaretskii
2016-07-09 18:57 ` N. Jackson [this message]
2021-07-08 0:44 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87poqm7i6q.fsf@moondust.awandering \
--to=nljlistbox2@gmail.com \
--cc=23929@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.