diff options
author | wm4 <wm4@nowhere> | 2020-01-30 14:00:41 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2020-01-30 14:13:35 +0100 |
commit | 355bb5b1e68ad1281d21d891b25f3bc917c307ff (patch) | |
tree | 1e856d924a5dcb56c8eda8eaf2408975a3588b62 /audio/audio_buffer.c | |
parent | 2fd34889fe7732eafc60e4acaf20c4fced9a4a81 (diff) | |
download | mpv-355bb5b1e68ad1281d21d891b25f3bc917c307ff.tar.bz2 mpv-355bb5b1e68ad1281d21d891b25f3bc917c307ff.tar.xz |
msg: fix some locking issues
The wakeup_log_file callback was still assuming that mp_msg_lock was
used to control the log file thread, but this changed while I was
writing this code, and forgot to update it. (It doesn't change any
state, which is untypical for condition variable usage. The state that
is changed is protected by another lock instead. But log_file_lock still
needs to be acquired to ensure the signal isn't sent while the thread is
right before the pthread_cond_wait() call, when the lock is held, but
the signal would still be lost.)
Because the buffer's wakeup callback now acquires the lock, the wakeup
callback must be called outside of the buffer lock, to keep the lock
order (log_file_lock > mp_log_buffer.lock). Fortunately, the wakeup
callback is immutable, or we would have needed another dumb leaf lock.
mp_msg_has_log_file() made a similar outdated assumption. But now access
to the log_file field is much trickier; just define that it's only to be
called from the thread that manages the msg state. (The calling code
could also just check whether the log-file option changed instead, but
currently that would be slightly more messy.)
Diffstat (limited to 'audio/audio_buffer.c')
0 files changed, 0 insertions, 0 deletions