[Haskell-cafe] GHC concurrency runtime "breaks" every 497 (and a bit) days

[Neil Davies]

In investigating ways of getting less jitter in the GHC concurrency
runtime I've found the following issue:

The GHC concurrency model does all of its time calculations in "ticks"
- a tick being fixed at 1/50th of a second. It performs all of these
calculations in terms the number of these ticks since the Unix epoch
(Jan 1970). Which is stored as an Int - unfortunately this 2^31 bits
overflows every 497 (and a bit) days.

When it does overflow any threads on the timer queue will either a)
run immediately or b) not be run for another 497 days - depending on
which way the sign changes. Also any timer calculation that spans the
wrapround will not be dealt with correctly.

Although this doesn't happen often (the last one was around Sat Sep 30
18:32:51 UTC 2006 and the next one will not be until Sat Feb  9
21:00:44 UTC 2008) I don't think we can leave this sort of issue in
the run-time system.

Take a look at the definition of getTicksofDay (in
base/include/HsBase.h (non-windows) / base/cbits/Win32Utils.c) and
getDelay (in base/GHC/Conc.lhs) to understand the details of the
issue.

I don't mind having a go at the base system to remove this problem -
but before I do I would like to canvas some opinions. I'll do that in
a separate thread.

Neil