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

[Nicolas Bertolotti]

(Forgot to do < Reply all >)

From: Nicolas Bertolotti
Sent: Tuesday, July 21, 2009 3:01 PM
To: 'Wesley W. Terpstra'
Subject: RE: [MLton] Problem with recent implementation of gettimeofday() on MinGW

I have observed this in practice.

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.

Both calls return the same value which, I guess, is caused by the face the SML side implementation of Time.now() manages to return the value from the previous call if the new call returns a smaller value.

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.

From: Wesley W. Terpstra [mailto:wesley at terpstra.ca]
Sent: Tuesday, July 21, 2009 2:34 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 10:20 AM, Nicolas Bertolotti <Nicolas.Bertolotti at mathworks.fr<mailto:Nicolas.Bertolotti at mathworks.fr>> wrote:
It seems to me that the new implementation of gettimeofday() (the one in the release candidate) is buggy. If a long running process calls gettimeofday() at the beginning of its execution and then calls it again after a few hours, it won't detect the wrap-around in PerformanceCounter and will not properly rebase the clock.

Have you observed this in practice? If yes, see if the attached patch helps. I'm at work, so can't test it beyond seeing if it compiles, but I believe it is anal enough to catch all possible wrap-arounds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20090721/7120ad2c/attachment.html