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

[Benjamin Franksen]

Neil Davies wrote:
> 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.

I answer but on this thread because IMO the overflow is a /much/ more
serious problem than the jitter due to unnecessarily coarse rounding.
Fortunately both can be solved together, by using 64 bit timestamps and the
highest available resolution. In my experience avoiding overflow by using
enough bits is a lot more reliable than any trick to 'handle' overflow.
With 64 bit timestamps, even if the base resolution is as small as one
nanosecond (which is lot more than you get on stock hardware even if you
use raw hardware timers), you still get overflow only every 585 years which
I would deem acceptable for all practical purposes.

BTW, the timer resolution should be available as a (platform dependent)
constant. Maybe it would even be useful to define a simple external
interface (to the RTS, i.e. in C) so that advanced users may plug in e.g.
extra hardware timers for ultimate resolution.

Cheers
Ben