| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Especially with other components (libavcodec, OSX stuff), the thread
list can get quite populated. Setting the thread name helps when
debugging.
Since this is not portable, we check the OS variants in waf configure.
old-configure just gets a special-case for glibc, since doing a full
check here would probably be a waste of effort.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Closer to the corresponding standard function pthread_cond_timedwait.
|
| |
|
|
|
|
|
| |
This was part of osdep/threads.c out of laziness. But it doesn't contain
anything OS dependent. Note that the rest of threads.c actually isn't
all that OS dependent either (just some minor ifdeffery to work around
the lack of clock_gettime() on OSX).
|
| |
|
|
|
|
| |
Makes working with the (still) single-threaded playback thread easier.
Might be reusable for other stuff.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
wm4