summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-08-14 19:34:53 +0200
committerwm4 <wm4@nowhere>2014-08-14 19:40:43 +0200
commita7107686d74250d4e4966b661c0e41994df71952 (patch)
tree4dfe0adb03c43389ac7888ad38f77a6e6c89f5bd
parent8f77d9df4aac53830ae45d64ad0ddfe2970a658a (diff)
downloadmpv-a7107686d74250d4e4966b661c0e41994df71952.tar.bz2
mpv-a7107686d74250d4e4966b661c0e41994df71952.tar.xz
client API: directly lock playloop
Until recently, vo_opengl could be accessed from a single thread only, due to the OpenGL API context being thread-specific. This issue doesn't exist anymore, because VOs run on their own thread. This means we can simply lock/unlock the playloop instead of doing something complicated to get the playloop thread to execute our code.
-rw-r--r--player/client.c7
1 files changed, 3 insertions, 4 deletions
diff --git a/player/client.c b/player/client.c
index bccf2d9605..0897534a15 100644
--- a/player/client.c
+++ b/player/client.c
@@ -749,12 +749,11 @@ int mpv_set_option_string(mpv_handle *ctx, const char *name, const char *data)
}
// Run a command in the playback thread.
-// Note: once some things are fixed (like vo_opengl not being safe to be
-// called from any thread other than the playback thread), this can
-// be replaced by a simpler method.
static void run_locked(mpv_handle *ctx, void (*fn)(void *fn_data), void *fn_data)
{
- mp_dispatch_run(ctx->mpctx->dispatch, fn, fn_data);
+ mp_dispatch_lock(ctx->mpctx->dispatch);
+ fn(fn_data);
+ mp_dispatch_unlock(ctx->mpctx->dispatch);
}
// Run a command asynchronously. It's the responsibility of the caller to