GNU bug report logs - #12430
Glitches caused by addition of psec to timers

Previous Next

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

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: Glitches caused by addition of psec to timers
Date: Wed, 12 Sep 2012 23:04:32 -0700

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 <at> cs.ucla.edu>
+
+	* NEWS: Document timer format change.
+
 2012-09-11  Paul Eggert  <eggert <at> 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 <at> 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 <at> 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 <at> 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 <at> 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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Thu, 13 Sep 2012 08:49:34 -0400

> 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

Message #13 received at 12430-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 12430-done <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Thu, 13 Sep 2012 09:26:07 -0700

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....

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eggert <at> cs.ucla.edu, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Thu, 13 Sep 2012 19:57:50 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 13 Sep 2012 08:49:34 -0400
> Cc: 12430 <at> 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?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Thu, 13 Sep 2012 11:48:48 -0700

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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: monnier <at> iro.umontreal.ca, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Thu, 13 Sep 2012 22:19:59 +0300

> Date: Thu, 13 Sep 2012 11:48:48 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Stefan Monnier <monnier <at> iro.umontreal.ca>, 12430 <at> 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.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Thu, 13 Sep 2012 12:37:23 -0700

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.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Thu, 13 Sep 2012 16:11:21 -0400

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.)

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
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.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: eggert <at> cs.ucla.edu, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Fri, 14 Sep 2012 09:32:01 +0300

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: eggert <at> cs.ucla.edu, 12430 <at> 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?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: monnier <at> iro.umontreal.ca, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Fri, 14 Sep 2012 09:32:43 +0300

> Date: Thu, 13 Sep 2012 12:37:23 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 12430 <at> 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.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Fri, 14 Sep 2012 09:18:47 -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?

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eggert <at> cs.ucla.edu, 12430 <at> debbugs.gnu.org
Subject: Re: bug#12430: Glitches caused by addition of psec to timers
Date: Fri, 14 Sep 2012 16:44:48 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu,  12430 <at> 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.

Previous Next

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