diff options
| -rw-r--r-- | libmpv/client.h | 6 | ||||
| -rw-r--r-- | player/client.c | 4 |
2 files changed, 6 insertions, 4 deletions
diff --git a/libmpv/client.h b/libmpv/client.h index d0d0402da7..0f2a455ae3 100644 --- a/libmpv/client.h +++ b/libmpv/client.h @@ -1228,11 +1228,13 @@ void mpv_set_wakeup_callback(mpv_handle *ctx, void (*cb)(void *d), void *d); * struct pollfd pfds[1] = { * { .fd = pipefd, .events = POLLIN }, * }; - * // Wait until there are possibly a new mpv events. + * // Wait until there are possibly new mpv events. * poll(pfds, 1, -1); * if (pfds[0].revents & POLLIN) { * // Empty the pipe. Doing this before calling mpv_wait_event() - * // ensures that no wakeups get missed. + * // ensures that no wakeups are missed. It's not so important to + * // make sure the pipe is really empty (it will just cause some + * // additional wakeups in unlikely corner cases). * char unused[256]; * read(pipefd, unused, sizeof(unused)); * while (1) { diff --git a/player/client.c b/player/client.c index c375a11d94..56b7029a42 100644 --- a/player/client.c +++ b/player/client.c @@ -42,9 +42,9 @@ /* * Locking hierarchy: * - * MPContext > mp_client_api.lock > mpv_handle.lock + * MPContext > mp_client_api.lock > mpv_handle.lock > * > mpv_handle.wakeup_lock * - * MPContext strictly speaking has no locks, and instead implicitly managed + * MPContext strictly speaking has no locks, and instead is implicitly managed * by MPContext.dispatch, which basically stops the playback thread at defined * points in order to let clients access it in a synchronized manner. Since * MPContext code accesses the client API, it's on top of the lock hierarchy. |