* bug#12430: Glitches caused by addition of psec to timers
@ 2012-09-13 6:04 Paul Eggert
2012-09-13 12:49 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Paul Eggert @ 2012-09-13 6:04 UTC (permalink / raw)
To: 12430
Tags: patch
A private correspondent pointed out that the higher-resolution time
stamps patch (see Bug#9000) changed the format of timers but some
Lisp code that accesses timer-list wasn't updated. The patch
below fixes the instances I found. This
patch should be applied anyway, for clarity, but this raises
a compatibility point. The old timer format (through 24.2) was:
[high-seconds low-seconds usecs repeat-delay function args idle-delay]
The new (24.3) format, introduced to the trunk on 2012-06-22, adds a
PSECS component after USECS, like this:
[high-seconds low-seconds usecs psecs repeat-delay function args idle-delay]
which means that old code like (aref timer 5) to get the function, no
longer has the intended meaning. Code is supposed to use
(timer--function timer) instead of (aref timer 5), but not everyone
got the memo apparently. Clearly this stuff should be documented in
NEWS so the patch below does that too.
My correspondent suggests that the new format be changed to put PSECS
at the end:
[high-seconds low-seconds usecs repeat-delay function args idle-delay psecs]
to support older code that uses aref or elt. Does this sound like a
good idea? It would cater to backward compatiblity better, but would
make the new code a bit weirder.
Here's the patch to fix the bugs mentioned above, which I plan to
install shortly:
=== modified file 'etc/ChangeLog'
--- etc/ChangeLog 2012-09-11 02:28:27 +0000
+++ etc/ChangeLog 2012-09-13 05:56:38 +0000
@@ -1,3 +1,7 @@
+2012-09-13 Paul Eggert <eggert@cs.ucla.edu>
+
+ * NEWS: Document timer format change.
+
2012-09-11 Paul Eggert <eggert@cs.ucla.edu>
Simplify, document, and port floating-point (Bug#12381).
=== modified file 'etc/NEWS'
--- etc/NEWS 2012-09-12 19:16:36 +0000
+++ etc/NEWS 2012-09-13 05:56:38 +0000
@@ -101,6 +101,11 @@
file-attributes and format-time-string, have been changed accordingly.
Old-format time stamps are still accepted.
+** The format of timers in timer-list and timer-idle-list is now
+[HIGH-SECONDS LOW-SECONDS USECS PSECS REPEAT-DELAY FUNCTION ARGS IDLE-DELAY].
+The PSECS slot is new, and uses picosecond resolution. It can be
+accessed via the new timer--psecs accessor.
+
** Emacs now generates backtraces on fatal errors.
On encountering a fatal error, Emacs now outputs a textual description
of the fatal signal, and a short backtrace on platforms like glibc
=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog 2012-09-13 02:41:46 +0000
+++ lisp/ChangeLog 2012-09-13 05:00:33 +0000
@@ -1,3 +1,11 @@
+2012-09-13 Paul Eggert <eggert@cs.ucla.edu>
+
+ Fix glitches caused by addition of psec to timers.
+ * image.el (image-animate-timer):
+ * time.el (display-time-world-timer):
+ Use timer--function and timer--args rather than raw access to
+ timer vector.
+
2012-09-13 Glenn Morris <rgm@gnu.org>
* emacs-lisp/bytecomp.el (byte-compile-warning-prefix):
=== modified file 'lisp/gnus/ChangeLog'
--- lisp/gnus/ChangeLog 2012-09-11 10:08:59 +0000
+++ lisp/gnus/ChangeLog 2012-09-13 05:00:33 +0000
@@ -1,3 +1,9 @@
+2012-09-13 Paul Eggert <eggert@cs.ucla.edu>
+
+ Fix glitches caused by addition of psec to timers.
+ * gnus-art.el (gnus-article-stop-animations): Use timer--function
+ rather than raw access to timer vector.
+
2012-09-11 Julien Danjou <julien@danjou.info>
* gnus-notifications.el (gnus-notifications): Check for nil values in
=== modified file 'lisp/gnus/gnus-art.el'
--- lisp/gnus/gnus-art.el 2012-08-14 05:34:20 +0000
+++ lisp/gnus/gnus-art.el 2012-09-13 05:00:33 +0000
@@ -4554,7 +4554,7 @@
(defun gnus-article-stop-animations ()
(dolist (timer (and (boundp 'timer-list)
timer-list))
- (when (eq (elt timer 5) 'image-animate-timeout)
+ (when (eq (timer--function timer) 'image-animate-timeout)
(cancel-timer timer))))
(defun gnus-stop-downloads ()
=== modified file 'lisp/image.el'
--- lisp/image.el 2012-08-15 16:29:11 +0000
+++ lisp/image.el 2012-09-13 05:00:33 +0000
@@ -645,8 +645,8 @@
(while tail
(setq timer (car tail)
tail (cdr tail))
- (if (and (eq (aref timer 5) 'image-animate-timeout)
- (eq (car-safe (aref timer 6)) image))
+ (if (and (eq (timer--function timer) 'image-animate-timeout)
+ (eq (car-safe (timer--args timer)) image))
(setq tail nil)
(setq timer nil)))
timer))
=== modified file 'lisp/time.el'
--- lisp/time.el 2012-05-04 06:13:18 +0000
+++ lisp/time.el 2012-09-13 05:00:33 +0000
@@ -575,7 +575,8 @@
(let ((list timer-list))
(while list
(let ((elt (pop list)))
- (when (equal (symbol-name (aref elt 5)) "display-time-world-timer")
+ (when (equal (symbol-name (timer--function elt))
+ "display-time-world-timer")
(cancel-timer elt)))))))
;;;###autoload
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 6:04 bug#12430: Glitches caused by addition of psec to timers Paul Eggert
@ 2012-09-13 12:49 ` Stefan Monnier
2012-09-13 16:26 ` Paul Eggert
2012-09-13 16:57 ` Eli Zaretskii
0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2012-09-13 12:49 UTC (permalink / raw)
To: Paul Eggert; +Cc: 12430
> My correspondent suggests that the new format be changed to put PSECS
> at the end:
> [high-seconds low-seconds usecs repeat-delay function args
> idle-delay psecs]
> to support older code that uses aref or elt. Does this sound like a
> good idea?
Yes.
> It would cater to backward compatiblity better, but would
> make the new code a bit weirder.
Ever so slightly.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 12:49 ` Stefan Monnier
@ 2012-09-13 16:26 ` Paul Eggert
2012-09-13 16:57 ` Eli Zaretskii
1 sibling, 0 replies; 13+ messages in thread
From: Paul Eggert @ 2012-09-13 16:26 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 12430-done
On 09/13/2012 05:49 AM, Stefan Monnier wrote:
> Yes.
OK, thanks, I did that as trunk bzr 110018 and am
marking this bug as done. The change was simpler than I
thought it would be, which could well mean that
I missed something....
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 12:49 ` Stefan Monnier
2012-09-13 16:26 ` Paul Eggert
@ 2012-09-13 16:57 ` Eli Zaretskii
2012-09-13 18:48 ` Paul Eggert
2012-09-13 21:35 ` Stefan Monnier
1 sibling, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2012-09-13 16:57 UTC (permalink / raw)
To: Stefan Monnier; +Cc: eggert, 12430
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 13 Sep 2012 08:49:34 -0400
> Cc: 12430@debbugs.gnu.org
>
> > My correspondent suggests that the new format be changed to put PSECS
> > at the end:
>
> > [high-seconds low-seconds usecs repeat-delay function args
> > idle-delay psecs]
>
> > to support older code that uses aref or elt. Does this sound like a
> > good idea?
>
> Yes.
Wouldn't it be better to leave timers at their previous size of 8, and
instead allow the usecs element be a floating-point number?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 16:57 ` Eli Zaretskii
@ 2012-09-13 18:48 ` Paul Eggert
2012-09-13 19:19 ` Eli Zaretskii
2012-09-13 21:35 ` Stefan Monnier
1 sibling, 1 reply; 13+ messages in thread
From: Paul Eggert @ 2012-09-13 18:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 12430
On 09/13/2012 09:57 AM, Eli Zaretskii wrote:
> Wouldn't it be better to leave timers at their previous size of 8, and
> instead allow the usecs element be a floating-point number?
That could introduce off-by-one errors due to rounding
issues.
We could have the usecs element be a list, though.
That is, (USECS PSECS) would stand for the sum of
USECS microseconds and PSECS picoseconds, whereas
a plain USECS would be treated as a microseconds count,
as before.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 18:48 ` Paul Eggert
@ 2012-09-13 19:19 ` Eli Zaretskii
2012-09-13 19:37 ` Paul Eggert
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2012-09-13 19:19 UTC (permalink / raw)
To: Paul Eggert; +Cc: 12430
> Date: Thu, 13 Sep 2012 11:48:48 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, 12430@debbugs.gnu.org
>
> On 09/13/2012 09:57 AM, Eli Zaretskii wrote:
> > Wouldn't it be better to leave timers at their previous size of 8, and
> > instead allow the usecs element be a floating-point number?
>
> That could introduce off-by-one errors due to rounding
> issues.
Not with correct programs that _want_ the sub-microsecond resolution.
> We could have the usecs element be a list, though.
> That is, (USECS PSECS) would stand for the sum of
> USECS microseconds and PSECS picoseconds, whereas
> a plain USECS would be treated as a microseconds count,
> as before.
Yes, that's also a possibility, although it is less compatible (e.g.,
fails the 'numberp' test). Any backward-compatible structure is
better than an incompatible one. If 'timerp' just checks the number
of elements in the array, so could some code out there.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 19:19 ` Eli Zaretskii
@ 2012-09-13 19:37 ` Paul Eggert
2012-09-13 20:11 ` Glenn Morris
2012-09-14 6:32 ` Eli Zaretskii
0 siblings, 2 replies; 13+ messages in thread
From: Paul Eggert @ 2012-09-13 19:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 12430
On 09/13/2012 12:19 PM, Eli Zaretskii wrote:
> Not with correct programs that _want_ the sub-microsecond resolution.
I don't see how rounding errors could be avoided. As a trivial example, if I
write '0.001' in Emacs Lisp, I get a number slightly bigger than 0.001
due to rounding error, so the underlying OS primitives (which always
get the ceiling of the delay request) would see two nanoseconds rather
than the one that I wanted. OK, so it's only a nanosecond off, but
the point is that Emacs shouldn't be munging the low-order
bits of users' requests.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 19:37 ` Paul Eggert
@ 2012-09-13 20:11 ` Glenn Morris
2012-09-14 6:32 ` Eli Zaretskii
1 sibling, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2012-09-13 20:11 UTC (permalink / raw)
To: Paul Eggert; +Cc: 12430
Paul Eggert wrote:
> I don't see how rounding errors could be avoided. As a trivial example, if I
> write '0.001' in Emacs Lisp, I get a number slightly bigger than 0.001
> due to rounding error, so the underlying OS primitives (which always
> get the ceiling of the delay request) would see two nanoseconds rather
> than the one that I wanted. OK, so it's only a nanosecond off, but
> the point is that Emacs shouldn't be munging the low-order
> bits of users' requests.
Maybe you should future-proof the timer format by jumping to units of
Planck time rather than picoseconds... I supposed you still need to
worry about portability between Universes though (please address in
Gnulib ASAP).
(I wonder when the first Emacs application will be written that has a
legitimate need to schedule a timer event with sub-millisecond
resolution.)
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 19:37 ` Paul Eggert
2012-09-13 20:11 ` Glenn Morris
@ 2012-09-14 6:32 ` Eli Zaretskii
1 sibling, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2012-09-14 6:32 UTC (permalink / raw)
To: Paul Eggert; +Cc: 12430
> Date: Thu, 13 Sep 2012 12:37:23 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: monnier@iro.umontreal.ca, 12430@debbugs.gnu.org
>
> On 09/13/2012 12:19 PM, Eli Zaretskii wrote:
>
> > Not with correct programs that _want_ the sub-microsecond resolution.
>
> I don't see how rounding errors could be avoided. As a trivial example, if I
> write '0.001' in Emacs Lisp, I get a number slightly bigger than 0.001
> due to rounding error, so the underlying OS primitives (which always
> get the ceiling of the delay request) would see two nanoseconds rather
> than the one that I wanted. OK, so it's only a nanosecond off, but
> the point is that Emacs shouldn't be munging the low-order
> bits of users' requests.
I will remember that when I write a hard-realtime application in Emacs
Lisp.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 16:57 ` Eli Zaretskii
2012-09-13 18:48 ` Paul Eggert
@ 2012-09-13 21:35 ` Stefan Monnier
2012-09-14 6:32 ` Eli Zaretskii
1 sibling, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-09-13 21:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 12430
> Wouldn't it be better to leave timers at their previous size of 8, and
> instead allow the usecs element be a floating-point number?
I doubt there's code out there that depends on the size of
this structure, so adding fields to it should be safe.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#12430: Glitches caused by addition of psec to timers
2012-09-13 21:35 ` Stefan Monnier
@ 2012-09-14 6:32 ` Eli Zaretskii
2012-09-14 13:18 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2012-09-14 6:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: eggert, 12430
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: eggert@cs.ucla.edu, 12430@debbugs.gnu.org
> Date: Thu, 13 Sep 2012 17:35:31 -0400
>
> > Wouldn't it be better to leave timers at their previous size of 8, and
> > instead allow the usecs element be a floating-point number?
>
> I doubt there's code out there that depends on the size of
> this structure, so adding fields to it should be safe.
But NOT adding fields is even safer, no?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#12430: Glitches caused by addition of psec to timers
2012-09-14 6:32 ` Eli Zaretskii
@ 2012-09-14 13:18 ` Stefan Monnier
2012-09-14 13:44 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-09-14 13:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 12430
>> > Wouldn't it be better to leave timers at their previous size of 8, and
>> > instead allow the usecs element be a floating-point number?
>> I doubt there's code out there that depends on the size of
>> this structure, so adding fields to it should be safe.
> But NOT adding fields is even safer, no?
In general, yes, but not if it is replaced by modifying another field.
And since the danger that we're trying to avoid is vanishingly small,
I'd rather not worry about it. If/when someone bumps into a package
that breaks because of it, we will see what to do.
> I will remember that when I write a hard-realtime application in
> Emacs Lisp.
Nanoseconds are real. Think about it: if the eldoc timer is always late
by a nanosecond each time, over your whole lifetime this might add up to
your wasting a measurable amount of your life waiting unnecessarily.
Do you really want to die cursing those wasted nanoseconds?
I didn't think so,
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#12430: Glitches caused by addition of psec to timers
2012-09-14 13:18 ` Stefan Monnier
@ 2012-09-14 13:44 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2012-09-14 13:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: eggert, 12430
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eggert@cs.ucla.edu, 12430@debbugs.gnu.org
> Date: Fri, 14 Sep 2012 09:18:47 -0400
>
> > I will remember that when I write a hard-realtime application in
> > Emacs Lisp.
>
> Nanoseconds are real. Think about it: if the eldoc timer is always late
> by a nanosecond each time, over your whole lifetime this might add up to
> your wasting a measurable amount of your life waiting unnecessarily.
> Do you really want to die cursing those wasted nanoseconds?
> I didn't think so,
If you studied the various OSes and worked with hard realtime programs
as much as I did, you wouldn't bet your life on the precision of their
timers.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-09-14 13:44 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-13 6:04 bug#12430: Glitches caused by addition of psec to timers Paul Eggert
2012-09-13 12:49 ` Stefan Monnier
2012-09-13 16:26 ` Paul Eggert
2012-09-13 16:57 ` Eli Zaretskii
2012-09-13 18:48 ` Paul Eggert
2012-09-13 19:19 ` Eli Zaretskii
2012-09-13 19:37 ` Paul Eggert
2012-09-13 20:11 ` Glenn Morris
2012-09-14 6:32 ` Eli Zaretskii
2012-09-13 21:35 ` Stefan Monnier
2012-09-14 6:32 ` Eli Zaretskii
2012-09-14 13:18 ` Stefan Monnier
2012-09-14 13:44 ` Eli Zaretskii
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).