path: root/osdep/timer.c
Commit message (Collapse)AuthorAgeFilesLines
* timer: remove unneeded time_t overflow checkwm42014-05-241-12/+1
| | | | | | | This is mostly covered by the OSX workaround, if the timeout is very high. It also means that with systems using 32 bit time_t, the time will overflow 2036 already, instead of 2037, but we don't consider this a problem.
* timer: workaround for crappy operating systemswm42014-05-231-0/+1
| | | | | | | | | | Some operating systems apparently can't deal with really long timeouts in pthread_cond_timedwait(). Passing a time about 300000 in the future makes the call return immediately. (tv_sec/time_t doesn't overflow in this situation.) Reduce the wait time to about 100 days, which seems to work fine. The list of affected OSes follows: OSX
* timer: fix previous commitwm42014-05-221-1/+1
| | | | | Sigh... of course the type of the (?:) exprsssion is double, so INT64_MAX was converted to double, which is a problem.
* timer: improve overflow checkswm42014-05-221-4/+5
| | | | | | | Probably more correct and better readable. Although the special-casing of 0x1p63 is weird in terms of readability (the value itself is INT64_MAX+1, so it's already outside of range, but INT64_MAX is not exactly representable with double precision).
* timer: fix (usually impossible) timespec.tv_sec overflowwm42014-05-221-1/+13
| | | | | | | This usually can't happen, because even if time_us (first input value) is INT64_MAX, the value added to tv_sec will be about 2^43, and tv_sec will be <2^31, far below a possible overflow in 64 bits. But should time_t be 32 bits (32 bit Linux/Windows?), an overflow could happen.
* timer: account for negative time valueswm42014-05-181-2/+6
| | | | | | | | It can easily happen that mp_time_us_to_timespec() gets a time in the past, and then the time difference will be negative. Regression introduced in commit f47a4fc3. Also fix an underflow check in mp_add_timeout().
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-3/+63
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* timer: add utility function to get relative timewm42014-02-281-0/+11
* timer: init only oncewm42014-02-101-1/+8
| | | | | | | | | | This avoids trouble if another mpv instance is initialized in the same process. Since timeBeginPeriod/timeEndPeriod are hereby not easily matched anymore, use an atexit() handler to call timeEndPeriod, so that we can be sure these calls are matched, even if we allow multiple initializations later when introducing the client API.
* Replace calls to usec_sleep()wm42013-05-261-6/+0
| | | | | | This is just dumb sed replacement to mp_sleep_us(). Also remove the now unused usec_sleep() wrapper.
* Replace all calls to GetTimer()/GetTimerMS()wm42013-05-261-10/+0
| | | | | | | | | | | | | | | | | | | | | | GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
* timer: refactor, add 64 bit timer functionwm42013-05-261-0/+82
Make OS specific timer code export a mp_raw_time_us() function, and add generic implementations of GetTimer()/GetTimerMS() using this function. New mpv code is supposed to call mp_time_us() in situations where precision is absolutely needed, or mp_time_s() otherwise. Make it so that mp_time_us() will return a value near program start. We don't set it to 0 though to avoid confusion with relative vs. absolute time. Instead, pick an arbitrary offset. Move the test program in timer-darwin.c to timer.c, and modify it to work with the generic timer functions.