Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,240
    • Issues 5,240
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 566
    • Merge requests 566
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #5865
Closed
Open
Issue created Feb 10, 2012 by joeyadams@trac-joeyadams

threadDelay is disrupted by system clock changes

threadDelay is sensitive to changes to the system clock. Two behaviors are observed:

  • When the system clock is moved forward, threadDelay will timeout prematurely, because it thinks that amount of time elapsed.
  • When the system clock is moved backward, threadDelay will take longer to complete, because it's waiting for the system clock to catch up.

Whether these behaviors are present depends on both the operating system and the use of -threaded. Here are the configurations I tested:

  • ghc-7.4.1 Linux 64-bit: Disrupted by both forward and backward clock changes
  • ghc-7.4.1 Linux 64-bit, -threaded: Disrupted only by backward clock changes
  • ghc-7.2.2 Windows 32-bit: Not disrupted by clock changes (behaves correctly)
  • ghc-7.2.2 Windows 32-bit, -threaded: Disrupted only by backward clock changes

To reproduce the problem, first compile the attached program. It uses System.Posix.Clock from the "clock" package to get the time, unaffected by system clock changes. Then run it. It will produce output like this:

0: 0s
1: 10s

Set the system clock forward by a minute. On Linux without -threaded, it will print something like this:

5: 50s
6: 52s

6 is printed 2 seconds after 5, because threadDelay didn't wait a full 10 seconds like it should have.

Now set the system clock backward by a minute. On Windows with -threaded, or on Linux with or without -threaded, it will print something like this:

3: 30s
4: 101s

4 is printed over a minute after 3, because threadDelay waited for the system clock to recover the time subtracted by changing the time.

For convenience, here's a way to fix the system clock on Linux after fiddling around with it:

sudo ntpdate pool.ntp.org

Digging through the source, each configuration seems to boil down to the following system calls:

  • Linux: gettimeofday (via getourtimeofday in posix/Itimer.c)
  • Linux, -threaded: gettimeofday, epoll_wait
  • Windows: Sleep
  • Windows, -threaded: GetSystemTimeAsFileTime, WaitForSingleObject

Perhaps the calls to gettimeofday and GetSystemTimeAsFileTime should be replaced with monotonic time functions (i.e. ones not affected by system clock changes):

  • Linux, FreeBSD: http://stackoverflow.com/q/211055/149391
  • Mac OS X: http://stackoverflow.com/a/6725161/149391
  • Windows: http://stackoverflow.com/q/211257/149391
Trac metadata
Trac field Value
Version 7.4.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking