| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Makes working with the (still) single-threaded playback thread easier.
Might be reusable for other stuff.
|
| |
|
|
|
|
|
|
|
| |
It's quite possible to overflow the calculation by setting the timeout
to high values. Limit it to INT_MAX, which should be safe. The issue is
mainly the secs variable.
timespec.tv_sec will normally be 64 bit on sane systems, and we assume
it can't overflow by adding INT_MAX to it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Usually, you have to call pthread_cond_timedwait() in a loop (because it
can wake up sporadically). If this function is used by another higher
level function, which uses a relative timeout, we actually have to
reduce the timeout on each iteration - or, simpler, compute the
"deadline" at the beginning of the function, and always pass the same
absolute time to the waiting function.
Might be unsafe if the system time is changed. On the other hand, this
is a fundamental race condition with these APIs.
|
| |
|
|
| |
Damn this overly verbose pthread API.
|
|
|
Also split the function itself into 3.
|
