From 09dd1ed47cbd6ea1e626b6bc2bfafa3af7d11cce Mon Sep 17 00:00:00 2001 From: wm4 Date: Sun, 8 Jun 2014 16:11:39 +0200 Subject: client API: minor documentation fixes/enhancements --- libmpv/client.h | 6 ++++-- 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. -- cgit v1.2.3