aboutsummaryrefslogtreecommitdiffhomepage
path: root/player
diff options
context:
space:
mode:
authorGravatar wm4 <wm4@nowhere>2018-04-15 15:09:41 +0200
committerGravatar Jan Ekström <jeebjp@gmail.com>2018-04-16 01:22:05 +0300
commit3d88e6f4c2da4c64e0daf658da2c97dff8c3963f (patch)
treebf00a4e64e7d292caeb8e1136002915ed4cdcf76 /player
parentf9bcb5c42c9a3adb54179ef154300734911ea2b5 (diff)
client API: fix potential sporadic freezes on termination
Although this was never observed to be happening, it seems definitely possible: we first tell the main thread to exit, and then we ask the main thread to do some work for us (with mp_dispatch_run()). Obviously this is racy, and the main thread could exit without doing this, which would block mp_dispatch_run() forever. Fix this by changing the order of operation, so that it makes sense. We could also just store the pthread_t of the main thread in some variable, but the fact that pthread_create() might set the pthread_t argument _after_ starting the thread makes this a bit messy (at least it doesn't seem to be guaranteed on a superficial look at the manpage).
Diffstat (limited to 'player')
-rw-r--r--player/client.c8
1 files changed, 4 insertions, 4 deletions
diff --git a/player/client.c b/player/client.c
index 1fe38881ad..edd929c203 100644
--- a/player/client.c
+++ b/player/client.c
@@ -452,16 +452,16 @@ static void mp_destroy_client(mpv_handle *ctx, bool terminate)
mpctx->stop_play = PT_QUIT;
mp_dispatch_unlock(mpctx->dispatch);
- // Stop the core thread.
+ pthread_t playthread;
+ mp_dispatch_run(mpctx->dispatch, get_thread, &playthread);
+
+ // Ask the core thread to stop.
pthread_mutex_lock(&clients->lock);
clients->terminate_core_thread = true;
pthread_mutex_unlock(&clients->lock);
mp_wakeup_core(mpctx);
// Blocking wait for all clients and core thread to terminate.
- pthread_t playthread;
- mp_dispatch_run(mpctx->dispatch, get_thread, &playthread);
-
pthread_join(playthread, NULL);
mp_destroy(mpctx);