diff options
author | wm4 <wm4@nowhere> | 2014-06-07 23:15:07 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2014-06-07 23:16:46 +0200 |
commit | 5cc68c792be1d0ae42017f6960ba1d0448646ff5 (patch) | |
tree | e8180a6373667a51855abcc41469d5ac98f27040 /libmpv/client.h | |
parent | fca608ccb95e4167e1885483dfd30ba71007cbb4 (diff) | |
download | mpv-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/client.h')
-rw-r--r-- | libmpv/client.h | 4 |
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 |