[MLton] Problem with recent implementation of gettimeofday() on MinGW

[Nicolas Bertolotti]

Right, my mistake.

Then, the only thing that we actually need is to use the "double" type.

The other change you propose would make it possible to go over the 209 year limit. I won't be there to see it being reached so it's fine for me :)

Thanks for your help

From: Wesley W. Terpstra [mailto:wesley at terpstra.ca]
Sent: Tuesday, July 21, 2009 4:20 PM
To: Nicolas Bertolotti
Cc: mlton at mlton.org
Subject: Re: [MLton] Problem with recent implementation of gettimeofday() on MinGW

On Tue, Jul 21, 2009 at 3:01 PM, Nicolas Bertolotti <Nicolas.Bertolotti at mathworks.fr<mailto:Nicolas.Bertolotti at mathworks.fr>> wrote:

I have a binary which ran for 12783 seconds and calls Time.now() once at the beginning of its execution and once at the end of its execution.



I could not identify the exact location of the overflow by looking at the code. I suspect the instruction:

nowMicroSeconds.QuadPart +=

                1000000 * deltaCounter.QuadPart / frequency.QuadPart;

But, in my point of view, it could only lead to a failure if the call occurs after (0xFFFFFFFFFFFFFFFFULL / 10000ULL) / 0xA6E78230ULL = 658767 seconds.
Actually, it would be 2^63/10^6/0xa6e78230 = 3294 seconds. That corresponds to what you saw. I'll note that your clock's frequency is significantly higher than mine!

My patch uses a double there now which definitely has enough precision. Even with your faster clock rate, the QueryPerformanceCounter won't wrap around for 209 years, so the overly anal check comparing the high resolution timer to the low resolution timer is unnecessary... Still, perhaps other systems have an even faster clock.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20090721/5eeaff64/attachment.html