summaryrefslogtreecommitdiffstats
path: root/osdep/threads.c
Commit message (Collapse)AuthorAgeFilesLines
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-111-13/+0
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* osdep: potentially fix compilation on OpenBSDwm42014-10-311-0/+1
| | | | | The <pthread_np.h> header expects that <pthread.h> was already included. We were including <pthread.h> only later via our threads.h.
* osdep: NetBSD pthread_setname_np()wm42014-10-221-0/+6
| | | | | | From: bugmen0t on github Fixes #1207.
* osdep: shorten thread name on glibc onlywm42014-10-201-3/+7
| | | | | Instead of affecting every platform, do this for glibc only (where it's known to be a problem), and only if the right error is returned.
* osdep: limit thread names to 16 characterswm42014-10-201-1/+1
| | | | | | | | | | | | | | | | It turns out the glibc people are very clever and return an error if the thread name exceeds the maximum supported kernel length, instead of truncating the name. So everyone has to hardcode the currently allowed Linux kernel name length limit, even if it gets extended later. Also the Lua script filenames could get too long; use the client name instead. Another strange thing is that on Linux, unrelated threads "inherit" the name by the thread they were created. This leads to random thread names, because there's not necessarily a strong relation between these threads (e.g. script command leads to filter recreation -> the filter's threads are tagged with the script's thread name). Unfortunate.
* Set thread name for debuggingwm42014-10-191-0/+16
| | | | | | | | | | 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.
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-47/+8
| | | | | | 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 namewm42014-04-231-2/+2
| | | | Closer to the corresponding standard function pthread_cond_timedwait.
* dispatch: move into its own source filewm42014-04-231-228/+0
| | | | | | | 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: fix wait time overflow checkwm42014-02-261-2/+2
| | | | | | | | | | | | | When passing a very large timeout to mpthread_cond_timed_wait(), the calculations could overflow, setting tv_sec to a negative value, and making the pthread_cond_timed_wait() call return immediately. This accidentally made Lua support poll and burn CPU for no reason. The existing overflow check was ineffective on 32 bit systems. tv_sec is usually a long, so adding INT_MAX to it will usually not overflow on 64 bit systems, but on 32 bit systems it's guaranteed to overflow. Simply fix by clamping against a relatively high value. This will work until 1 week before the UNIX time wraps around in 32 bits.
* threads: add a dispatch queue thingwm42014-02-101-0/+229
| | | | | | Makes working with the (still) single-threaded playback thread easier. Might be reusable for other stuff.
* threads: avoid timeout calculation overflowwm42014-02-101-0/+3
| | | | | | | | | 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.
* threads: add function to calculate deadline for timed waitswm42014-01-311-3/+12
| | | | | | | | | | | | 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 mutexeswm42014-01-311-0/+11
| | | | Damn this overly verbose pthread API.
* stream: split out pthread helper functionwm42013-11-171-0/+57
Also split the function itself into 3.