RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2025-04-18 05:07:18 +00:00
Code Issues Releases Wiki Activity

client API: minor documentation fixes/enhancements

Browse Source
This commit is contained in:
wm4 2014-06-08 16:11:39 +02:00
parent 51834592fc
commit 09dd1ed47c
2 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
libmpv/client.h
View File

@ -1228,11 +1228,13 @@ void mpv_set_wakeup_callback(mpv_handle *ctx, void (*cb)(void *d), void *d);
* struct pollfd pfds[1] = { * struct pollfd pfds[1] = {
* { .fd = pipefd, .events = POLLIN }, * { .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); * poll(pfds, 1, -1);
* if (pfds[0].revents & POLLIN) { * if (pfds[0].revents & POLLIN) {
* // Empty the pipe. Doing this before calling mpv_wait_event() * // 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]; * char unused[256];
* read(pipefd, unused, sizeof(unused)); * read(pipefd, unused, sizeof(unused));
* while (1) { * while (1) {

4
player/client.c
View File

@ -42,9 +42,9 @@
/* /*
* Locking hierarchy: * 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 * by MPContext.dispatch, which basically stops the playback thread at defined
* points in order to let clients access it in a synchronized manner. Since * 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. * MPContext code accesses the client API, it's on top of the lock hierarchy.