#5865: threadDelay is disrupted by system clock changes
---------------------------------+------------------------------------------
Reporter: joeyadams | Owner: pcapriotti
Type: bug | Status: patch
Priority: high | Milestone: 7.4.2
Component: Runtime System | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by pcapriotti):
A comment in `rts/win32/GetTime.c` says:
{{{
// getProcessElapsedTime relies on QueryPerformanceFrequency
// which should be available on any Windows computer thay you
// would want to run Haskell on. Satnam Singh, 5 July 2010.
}}}
so I assumed the same would hold for base.
I agree we should check the return value of QPF, though, but I would
assume that if QPF returns true, then QPC is not going to fail.
I'm not sure what to make of the virtualdub.org post. If it's really as
bad as it says there, should we actually be using `timeGetTime`, which has
>5ms resolution? And is `timeGetTime` actually monotonic (I understand
`GetTickCount` is not)?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5865#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
