id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,os,architecture,failure,difficulty,testcase,blockedby,blocking,related
7325,threadDelay mistreats minBound and maxBound in some configurations,joeyadams,,"threadDelay currently treats minBound and maxBound incorrectly in some cases.  This breaks the following idiom ([http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async.html#Concurrently 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.",bug,new,high,7.6.2,Runtime System,7.6.1,,,johan.tibell@…,Unknown/Multiple,Unknown/Multiple,Incorrect result at runtime,Unknown,,,,