threadDelay mistreats minBound and maxBound in some configurations
|Reported by:||joeyadams||Owned by:|
|Type of failure:||Incorrect result at runtime||Difficulty:||Unknown|
|Test Case:||Blocked By:|
threadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom (as seen in the async package):
forever (threadDelay maxBound)
On Linux (Ubuntu 10.04 64-bit) without -threaded, threadDelay maxBound returns immediately. For lower numbers on the same order of magnitude, it behaves non-deterministically. For example, given this program:
import Control.Concurrent import Control.Monad main = forM_ [6244222868950683224..] $ \i -> do print i threadDelay i
threadDelay returns immediately in some cases but not in others. If I compile and run it in bash like this:
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound
The bug usually appears, but if I run it like this:
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ./threadDelay-maxBound
The bug does not appear (threadDelay blocks like it should). Thus, the program is affected by a very subtle difference in how it is invoked. Perhaps it is sensitive to file descriptor numbers.
On Windows without -threaded, threadDelay maxBound seems to work, but threadDelay minBound blocks rather than returning immediately.