[Haskell-cafe] threadDelay delays less time than expected (Windows)

[Bardur Arantsson]

On 2016-12-29 19:54, Sven Panne wrote:
> 2016-12-29 17:27 GMT+01:00 Joey Hess <id at joeyh.name <mailto:id at joeyh.name>>:
> 
>     [...] It would perhaps be good for the documentation for threadDelay
>     to point
>     out that it can delay for a maximum of 71 minutes on 32 bit systems, and
>     point to the unbounded-delays package.
> 
> 
> .... or even better: Absorb the functions from unbounded-delays into
> base. In their current state, I would consider both threadDelay and
> timeout API bugs,
> see http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_revised.htm
> (/"//Make interfaces easy to use correctly and hard to use
> incorrectly."). /Perhaps we should add:
> 

+1.

Another, perhaps better, alternative would be to have something like a
"TimeDiff" type in base, but an actual *duration* in *physical* time (no
leap seconds, no calendar nonsense, etc.).

This is one of those big mistakes almost everyone made in the past[1].
*Physical* time is so much different from *calendar* time that it really
needs completely different representations and operations. (Of course
there must be *some* way to 'convert', but those conversions are
inherently dangerous and should be clearly marked as such.)

>    genericThreadDelay :: Integral i => i -> IO ()

I would be much happier with a signature of

   threadDelay :: Duration -> IO ()

with a few safe constructors for Duration, e.g. "daysToDuration :: Int
-> Duration" and "millisToDuration :: ..." (etc.). We might arguably
want "Maybe Duration" as the return type, but that may be pushing it.

*THAT* is how you make this particular API hard to misuse. I don't know
about you, but I always end up counting zeroes multiple times when
writing a "threadDelay ..." line.

Regards,

[1] Bascially before JodaTime made ordinary developers aware of just how
complex this Time/Date stuff really is and the importance of clearly
separating the concept of "calendar" time vs. "physical" time.