diff options
author | wm4 <wm4@nowhere> | 2020-01-29 23:34:59 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2020-01-29 23:34:59 +0100 |
commit | 2fd34889fe7732eafc60e4acaf20c4fced9a4a81 (patch) | |
tree | 13cac1a1df99f0f7d0bf0d1191b337482a826bfd /stream/stream.c | |
parent | 1caf90a3f7c9b3bb160b73c6b674f39a1d89ed85 (diff) | |
download | mpv-2fd34889fe7732eafc60e4acaf20c4fced9a4a81.tar.bz2 mpv-2fd34889fe7732eafc60e4acaf20c4fced9a4a81.tar.xz |
msg: make --log-file buffered through a thread
Until now --log-file performed a blocking write to the log file, which
made any calling thread block for I/O. It even explicitly flushed after
every line (to make it tail-able, or to ensure a hard crash wouldn't
lose any of the output). This wasn't so good, because it could cause
real playback problems, which made it infeasible to enable it by
default.
Try to buffer it through a ring buffer and a thread. There's no other
choice but to use a thread, since async I/O on files is generally a big
and unportable pain. (We very much prefer portable pain.) Fortunately,
there's already a ring buffer (mp_log_buffer, normally for the client
API logging hook). This still involves some pretty messy locking. Give
each mp_log_buffer its own lock to make this easier.
This still makes calling threads block if the log buffer is full (unlike
with client API log buffers, which just drop messages). I don't want log
messages to get lost for this purpose. This also made locking pretty
complicated (without it, mp_log_buffer wouldn't have needed its own
lock). Maybe I'll remove this blocking again when it turns out to be
nonsense.
(We could avoid wasting an entire thread by "reusing" some other thread.
E.g. pick some otherwise not real time thread, and make it react to the
log buffer's wakeup callback. But let's not. It's complicated to abuse
random threads for this. It'd also raise locking complexity, because we
still want it to block on a full buffer.)
Diffstat (limited to 'stream/stream.c')
0 files changed, 0 insertions, 0 deletions