summaryrefslogtreecommitdiffstats
path: root/libmpv
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-06-07 23:15:07 +0200
committerwm4 <wm4@nowhere>2014-06-07 23:16:46 +0200
commit5cc68c792be1d0ae42017f6960ba1d0448646ff5 (patch)
treee8180a6373667a51855abcc41469d5ac98f27040 /libmpv
parentfca608ccb95e4167e1885483dfd30ba71007cbb4 (diff)
downloadmpv-5cc68c792be1d0ae42017f6960ba1d0448646ff5.tar.bz2
mpv-5cc68c792be1d0ae42017f6960ba1d0448646ff5.tar.xz
client API: restructure waiting, do log msg wakeup properly
Until now, availability of new log messages (through the mechanism associated with mpv_request_log_messages()) did not wakeup the client API properly. Commit 3b7402b5 was basically a hack to improve that somewhat, but it wasn't a solution. The main problem is that the client API itself is producing messages, so the message callback would attempt to lock the client API lock, resulting in a deadlock. Even if the lock was recursive, we'd run into lock-order issues. Solve this by using a separate lock for waiting and wakeup. Also, since it's a natural addition, avoid redundant wakeups. This means the wakeup callback as well as the wakeup pipe will be triggered only once until the next mpv_wait_event() call happens. This might make the wakeup callback be invoked in a reentrant way for the first time, for example if a mpv_* function prints to a log. Adjust the docs accordingly. (Note that non-reentrant beheavior was never guaranteed - basically the wakeup callback is somewhat dangerous and inconvenient.) Also remove some traces of unneeded code. ctx->shutdown for one was never set, and probably a leftover of an abandoned idea.
Diffstat (limited to 'libmpv')
-rw-r--r--libmpv/client.h4
1 files changed, 3 insertions, 1 deletions
diff --git a/libmpv/client.h b/libmpv/client.h
index cc4ff99088..d0d0402da7 100644
--- a/libmpv/client.h
+++ b/libmpv/client.h
@@ -1175,7 +1175,9 @@ void mpv_wakeup(mpv_handle *ctx);
* must not make any assumptions of the environment, and you must return as
* soon as possible. You are not allowed to call any client API functions
* inside of the callback. In particular, you should not do any processing in
- * the callback, but wake up another thread that does all the work.
+ * the callback, but wake up another thread that does all the work. It's also
+ * possible that the callback is called from a thread while a mpv API function
+ * is called (i.e. it can be reentrant).
*
* In general, the client API expects you to call mpv_wait_event() to receive
* notifications, and the wakeup callback is merely a helper utility to make