\documentclass[]{article}
\usepackage{amsmath,graphicx,supertabular,hyperref,tabularx,ifthen}
\title{TIP \#302: Fix "after"'s Sensitivity To Adjustments Of System Clock}
\date{December 13, 2006}
\author{Alexandre Ferrieux, Kevin Kenny}
\urlstyle{sf}
\setlength{\parskip}{1ex}
\setlength{\parindent}{0pt}
\def\tipversion$#1${\texttt{\$#1\$}}
\def\tiplangle#1{\ensuremath{<}}
\def\tiprangle#1{\ensuremath{>}}
\def\tipbar#1{\ensuremath{|}}
\def\tipmail#1#2{\(\langle\){\small\expandafter\url{#1@#2}}\(\rangle\)}
\ifx\pdfoutput\undefined
\newcommand{\tipimage}[2]{\typeout{Make sure you download #1.eps}\ifthenelse{\lengthtest{0.8\textwidth>#2}\and\lengthtest{0pt<#2}}{\includegraphics{#1.eps}}{\includegraphics[width=0.8\textwidth]{#1.eps}}}
\newcommand{\tipxref}[1]{}
\newcommand{\tipxrefend}{}
\else
\newcommand{\tipimage}[2]{\typeout{Make sure you create #1.pdf}\ifthenelse{\lengthtest{0.8\textwidth>#2}\and\lengthtest{0pt<#2}}{\includegraphics{#1.pdf}}{\includegraphics[width=0.8\textwidth]{#1.pdf}}}
\pdfcatalog{/PageMode /UseOutlines}
\newcommand{\tipxref}[1]{\pdfannotlink attr {/C [0.5 0.5 1.0] /Border [0 0 1]} goto name {#1}}
\newcommand{\tipxrefend}{\pdfendlink}
\fi
\newenvironment{tipabstract}{\begin{abstract}}{\end{abstract}}
\begin{document}\maketitle
\begin{center}\begin{tabularx}{\linewidth}{|r@{: }X|}\hline
\textbf{TIP \#302}&\textbf{Fix "after"'s Sensitivity To Adjustments Of System Clock}\\\hline
Author&

Alexandre Ferrieux \tipmail{alexandre.ferrieux}{gmail.com}
\par
Kevin Kenny \tipmail{kennykb}{acm.org}
\\
Created&Wednesday, \(\text{13}^{\text{th}}\) December 2006\\
Type&Project\\
Tcl Version&\(8.7\)\\
State&Draft\\
Vote&Pending\\
Version&\tipversion$Revision: 1.3 $\\
Keywords&Tcl, time changes\\
Post History&\\
\hline\end{tabularx}\end{center}
\thispagestyle{empty}\pagestyle{empty}
\begin{tipabstract}

Currently, \textbf{after} tasks can be drastically delayed or sped up simply by adjusting the system clock. This is due to the implementation's use of an \textit{absolute} target date based on the system clock. The idea of this TIP is to use another timebase for this purpose: the count of ticks from boot, which is not affected by system time adjustments.
\end{tipabstract}
\tableofcontents\setcounter{page}{0}\clearpage\pagestyle{plain}

\section{Background}

The basis of the implementation of \textbf{after} is, on each call to \textbf{vwait}, to compute the \textit{timeout} argument to select() by difference between the stored target date of the earliest event and the current system date (\textit{gettimeofday()}). This is perfect while the system date ticks regularly. But if, say, the clock is set back by 5 minutes, then an after handler scheduled 1 second ago which was just about to fire, will have 5 minutes yet to wait before its (unmodified) target date is reached. So, if this handler was part of a 1-Hz periodic task, there will be a huge gap of 5:01 between two ticks at that point. If some other component is expecting some kind of regularity, even with a conservative timeout of 10 times the expected period, it \textit{will} time out, decide the periodic task is dead, and possibly take drastic action.

\section{Proposed Change}

This TIP proposes to use other timebases instead of gettimeofday() in the vwait/after code: \textbf{times()} in unix, \textbf{GetTickCount()} in Windows. These clocks suffer \textit{no} sysadmin tinkering.

\section{Potential Break Of Compatibility}

It has been objected that \textit{some} applications today may be using \textbf{after} with an \textit{absolute} spirit; IOW such apps are supposed to \textit{rely} on the fact that the after handler will fire when the system clock equals the target date computed once for all when \textbf{after} was called. A prototype example would be a crontab-like task, which would itself compute the offset by difference between the target date and the current \textbf{clock seconds}.

\subsection{Arguments For Breaking It Anyway}
\begin{enumerate}
\item{}
This \textit{absolute} interpretation is far from being natural, because \textbf{after}'s argument is an \textit{offset}.
\setcounter{enumi}{1}
\item{}
This technique is not usable for a longer range than 25 days (MAXINT milliseconds), so not applicable e.g. for a personal schedule.
\setcounter{enumi}{2}
\item{}
The \textbf{overwhelming} majority of uses of \textbf{after} takes the \textit{relative} interpretation (periodic tasks, timeouts) and \textit{cannot} work correctly today.
\setcounter{enumi}{3}
\item{}
If this TIP were implemented incompatibly (i.e. without a specific flag to \textbf{after}), those \textit{absolute-minded} apps could simply be adapted \textit{and} improved in both robustness and range by using a periodic task which polls \textbf{clock seconds}.
\setcounter{enumi}{4}
\item{}
There is little evidence that the total number of \textit{absolute-minded} apps exceeds \textbf{one} (see discussion on \url{news:comp.lang.tcl} ``[after] fooled by shifting date'')
\end{enumerate}

\section{Syntax For Not Breaking It If Deemed Useful}

Of course, if this supposed singleton is in fact many, or has enough weight to preclude an improvement of the rest of Tcl timers, we can do:

\begin{quote}
\textbf{after -robust} \textit{millisecs}
\end{quote}

or any other colorful option name. But in this case there is a high risk that: \textit{either} \textbf{after -robust} becomes the dominant use, thus cluttering the code in many places, \textit{or} people remain largely unaware of the problem, stick to the default \textbf{after}, and space shuttles fall by dozens.

\section{Escalation To The TCT}

I'll leave it to the TCT to arbitrate, and decide whether \textit{fixing} a widely used core primitive can outweigh breaking a rare and clumsy use.

\section{Reference Implementation}

I have not yet written a reference implementation; I assume somebody with a more fluent practice of the core will do so more efficiently. However, gentle arm twisting, etc.

\section{Copyright}

This document has been placed in the public domain.

\section{Comments}

The \textit{times} function in Unix is \textit{not} an appropriate time base. It reports the user and system time (CPU time, in other words) of the currently executing process and its children. As far as I have been able to determine, Unix assumes that the system time reported by \textit{gettimeofday} is the sole time base for absolute timing; if multiple timers are required in a single process, \textit{gettimeofday} appears to be the only reference that is available.

\section{Colophon}

\textit{TIP AutoGenerator --- written by Donal K. Fellows}
\end{document}
