aboutsummaryrefslogtreecommitdiffhomepage
path: root/osdep/threads.h
Commit message (Collapse)AuthorAge
* threads: use mpv time for mpthread_cond_timedwait wrapperGravatar wm42014-05-18
| | | | | | 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.
* threads: fix function nameGravatar wm42014-04-23
| | | | Closer to the corresponding standard function pthread_cond_timedwait.
* dispatch: move into its own source fileGravatar wm42014-04-23
| | | | | | | 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).
* threads: add a dispatch queue thingGravatar wm42014-02-10
| | | | | | Makes working with the (still) single-threaded playback thread easier. Might be reusable for other stuff.
* threads: add function to calculate deadline for timed waitsGravatar wm42014-01-31
| | | | | | | | | | | | 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.
* threads: add wrapper for initializing recursive mutexesGravatar wm42014-01-31
| | | | Damn this overly verbose pthread API.
* stream: split out pthread helper functionGravatar wm42013-11-17
Also split the function itself into 3.