[MPlayer-dev-eng] [PATCH] 64-bit get time 2nd try

[Reimar Döffinger]

On Sat, Oct 09, 2010 at 06:05:25PM +0200, Dan Oscarsson wrote:
> I can add on linux a monotonic clock is used (for all timer calls) it
> you want it. I do not know how often NTP goes in and changes the clock.

Usually never. Which is why it generally works at all.

> On MS Windows I can add high precision timers to get a better clock
> there, though I cannot test it.

Rather pointless with a scheduler precision that is not any more accurate.

> The av_gettime in ffmpeg uses the Posix gettimeofday call - how is that
> handled when ffmpeg is compiled on MS Windows?

It exists on Windows but is not monotonic.

> +// Returns current time in microseconds in 64 bit quantity so it does not wrap
> +uint64_t get_time(void)
> +{
> +  uint64_t t;
> +
> +  if (wraps == -1) {
> +    prev_time = (uint64_t)1000 * timeGetTime();
> +    wraps = 0;
> +  }
> +  t = (uint64_t)1000 * (wraps * (uint64_t)0x100000000 + timeGetTime());
> +  if (prev_time > t) {
> +     wraps++;
> +     t += 1000 * (uint64_t)0x100000000;
> +  }

Of course this can't detect wraps if there's more than those 44 days
between calls.
You're just moving the problem from "you have to think about wrapping"
to "you might want to consider those hacks that have some
obscure, rare and OS-specific ways of failing. But maybe you
can just ignore it".
Without a significantly better reason for it than "because I can"
or "because I am too lazy to think when handling time", this is
and stays rejected, even more so since the function is underspecified
as to what exactly it is _supposed_ to do so it is impossible to
review whether it can be considered correct or not.