aboutsummaryrefslogtreecommitdiffhomepage
path: root/osdep/threads.c
Commit message (Collapse)AuthorAge
* Revert "osdep: NetBSD pthread_setname_np()"Gravatar wm42017-06-22
| | | | | | | | | | This reverts commit 2e81698d2809836d4cd7f754a78598e7bdf96c0b. Seems like this was a patch applied from someone who can't agree to LGPL relicensing (see previous commit), with the author field not properly set. This is not so important anyway, so just revert it.
* win32: pthread: use the new thread naming APIGravatar James Ross-Gowan2017-05-18
| | | | | | | Windows, as of the Creators Update, finally has a sane API for giving a name to a thread that can be used by debuggers. This is similar to pthread_setname_np on Linux and some Unixes. Expose it in the pthread wrapper and use it for mpthread_set_name().
* Relicense some non-MPlayer source files to LGPL 2.1 or laterGravatar wm42016-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 wrappersGravatar wm42015-05-11
| | | | | | | 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 OpenBSDGravatar wm42014-10-31
| | | | | 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()Gravatar wm42014-10-22
| | | | | | From: bugmen0t on github Fixes #1207.
* osdep: shorten thread name on glibc onlyGravatar wm42014-10-20
| | | | | 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 charactersGravatar wm42014-10-20
| | | | | | | | | | | | | | | | 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 debuggingGravatar wm42014-10-19
| | | | | | | | | | 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 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: fix wait time overflow checkGravatar wm42014-02-26
| | | | | | | | | | | | | 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 thingGravatar wm42014-02-10
| | | | | | Makes working with the (still) single-threaded playback thread easier. Might be reusable for other stuff.
* threads: avoid timeout calculation overflowGravatar wm42014-02-10
| | | | | | | | | 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 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.