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 /audio/chmap.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 'audio/chmap.h')
0 files changed, 0 insertions, 0 deletions