RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/common/msg_control.h

44 lines
1.5 KiB
C
Raw Permalink Normal View History

msg: move special declarations to msg_control.h While almost everything uses msg.h, the moved definitions are rarely needed by anything.
2014-01-16 20:24:39 +00:00
#ifndef MP_MSG_CONTROL_H
#define MP_MSG_CONTROL_H
#include <stdbool.h>
struct mpv_global;
player: get rid of mpv_global.opts This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
2018-05-21 14:25:52 +00:00
struct MPOpts;
msg: move special declarations to msg_control.h While almost everything uses msg.h, the moved definitions are rarely needed by anything.
2014-01-16 20:24:39 +00:00
void mp_msg_init(struct mpv_global *global);
void mp_msg_uninit(struct mpv_global *global);
player: get rid of mpv_global.opts This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
2018-05-21 14:25:52 +00:00
void mp_msg_update_msglevels(struct mpv_global *global, struct MPOpts *opts);
msg: move special declarations to msg_control.h While almost everything uses msg.h, the moved definitions are rarely needed by anything.
2014-01-16 20:24:39 +00:00
void mp_msg_force_stderr(struct mpv_global *global, bool force_stderr);
bool mp_msg_has_status_line(struct mpv_global *global);
player: make sure version information is always included in --log-file If --log-file was used in config files, this could be missing due to the exact timing when the messages are print, and when the options are applied. Fix this by always dumping the version again when a log file is opened.
2017-05-22 16:30:39 +00:00
bool mp_msg_has_log_file(struct mpv_global *global);
player: remove mechanisms for better logging with repl.lua As preparation for making repl.lua part of the core (maybe), add some mechanisms which are supposed to improve its behavior. Add a silent mode. Calling mpv_request_log_messages() with the log level name prefixed with "silent:" will disable logging from the API user's perspective. But it will keep the log buffer, and record new messages, without returning them to the user. If logging is enabled again by requesting the same log level without "silent:" prefix, the buffered log messages are returned to the user at once. This is not documented, because it's far too messy and special as that I'd want anyone to rely on this behavior, but it will be perfectly fine for an internal script. Another thing is that we record early startup messages. The goal is to make the repl.lua script show option and config parsing file errors. This works only with the special "terminal-default" log level. In addition, reduce the "terminal-default" capacity to only 100 log messages. If this is going to be enabled by default, it shouldn't use too much resources.
2019-11-17 23:44:12 +00:00
void mp_msg_set_early_logging(struct mpv_global *global, bool enable);
msg: move special declarations to msg_control.h While almost everything uses msg.h, the moved definitions are rarely needed by anything.
2014-01-16 20:24:39 +00:00
command: make the "run" command work on Windows too Do so by using mp_subprocess(). Although this uses completely different code on Unix too, you shouldn't notice a difference. A less ncie thing is that this reserves an entire thread while the command is running (which wastes some memory for stack, at least). But this is probably still the simplest way, and the fork() trick is apparently not implementable with posix_subprocess().
2015-01-01 19:37:49 +00:00
void mp_msg_flush_status_line(struct mp_log *log);
msg: add a mechanism to output messages to a ringbuffer Until now, mp_msg output always went to the terminal. There was no way to grab the stream of output messages. But this will be needed by various future changes: Lua scripts, slave mode, client library... This commit allows registering a ring buffer. A callback would be more straight-forward, but since msg.c sits at the bottom of the lock hierarchy (it's used by virtually everything), this would probably be a nightmare. A ring buffer will be simpler and more predictable in the long run. We allocate new memory for each ringbuffer entry, which is probably a bit expensive. We could try to be clever and somehow pack the data directly into the buffer, but I felt like this wouldn't be worth the complexity. You'd have to copy the data a bunch of times anyway. I'm hoping that we can get away with using the ringbuffer mechanism for low frequency important messages only (and not e.g. for high volume debug messages), so the cost doesn't matter that much. A ringbuffer has a simple, single log level. I considered allowing --msglevel style per-prefix configuration for each ringbuffer, but that would have been pretty complicated to implement, and wouldn't have been that useful either.
2014-01-16 20:26:31 +00:00
struct mp_log_buffer_entry {
char *prefix;
int level;
char *text;
};
client API: allow using msg-level option for log messages Client API users can enable log output with mpv_request_log_messages(). But you can enable only a single log level. This is normally enough, but the --msg-level option (which controls the terminal log level) provides more flexibility. Due to internal complexity, it would be hard to provide the same flexibility for each client API handle. But there's a simple way to achieve basically the same thing: add an option that sends log messages to the API handle, which would also be printed to the terminal as by --msg-level. The only change is that we don't disable this logic if the terminal is disabled. Instead we check for this before the message is output, which in theory can lower performance if messages are being spammed. It could be handled with some more effort, but the gain would be negligible.
2015-06-20 19:40:47 +00:00
// Use --msg-level option for log level of this log buffer
#define MP_LOG_BUFFER_MSGL_TERM (MSGL_MAX + 1)
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.)
2020-01-29 22:34:59 +00:00
// For --log-file; --msg-level, but at least MSGL_DEBUG
#define MP_LOG_BUFFER_MSGL_LOGFILE (MSGL_MAX + 2)
client API: allow using msg-level option for log messages Client API users can enable log output with mpv_request_log_messages(). But you can enable only a single log level. This is normally enough, but the --msg-level option (which controls the terminal log level) provides more flexibility. Due to internal complexity, it would be hard to provide the same flexibility for each client API handle. But there's a simple way to achieve basically the same thing: add an option that sends log messages to the API handle, which would also be printed to the terminal as by --msg-level. The only change is that we don't disable this logic if the terminal is disabled. Instead we check for this before the message is output, which in theory can lower performance if messages are being spammed. It could be handled with some more effort, but the gain would be negligible.
2015-06-20 19:40:47 +00:00
msg: add a mechanism to output messages to a ringbuffer Until now, mp_msg output always went to the terminal. There was no way to grab the stream of output messages. But this will be needed by various future changes: Lua scripts, slave mode, client library... This commit allows registering a ring buffer. A callback would be more straight-forward, but since msg.c sits at the bottom of the lock hierarchy (it's used by virtually everything), this would probably be a nightmare. A ring buffer will be simpler and more predictable in the long run. We allocate new memory for each ringbuffer entry, which is probably a bit expensive. We could try to be clever and somehow pack the data directly into the buffer, but I felt like this wouldn't be worth the complexity. You'd have to copy the data a bunch of times anyway. I'm hoping that we can get away with using the ringbuffer mechanism for low frequency important messages only (and not e.g. for high volume debug messages), so the cost doesn't matter that much. A ringbuffer has a simple, single log level. I considered allowing --msglevel style per-prefix configuration for each ringbuffer, but that would have been pretty complicated to implement, and wouldn't have been that useful either.
2014-01-16 20:26:31 +00:00
struct mp_log_buffer;
struct mp_log_buffer *mp_msg_log_buffer_new(struct mpv_global *global,
client API: call wakeup callback if there are new messages Listening on messages currently uses polling (every time mpv_wait_event() has no new events, the message buffer is polled and a message event is possibly created). Improve this situation a bit, and call the user-supplied wakeup callback. This will increase the frequency with which the wakeup callback is called, but the client is already supposed to be able to deal with this situation. Also, as before, calling mpv_wait_event() from the wakeup callback is forbidden, so the client can't read new messages from the callback directly. The wakeup pipe is written either. Since the wakeup pipe is created lazily, we can't access the pipe handle without creating a race condition or a deadlock. (This is actually very silly, since in practice the race condition won't matter, but for now let's keep it clean.)
2014-06-06 17:24:30 +00:00
int size, int level,
void (*wakeup_cb)(void *ctx),
void *wakeup_cb_ctx);
msg: add a mechanism to output messages to a ringbuffer Until now, mp_msg output always went to the terminal. There was no way to grab the stream of output messages. But this will be needed by various future changes: Lua scripts, slave mode, client library... This commit allows registering a ring buffer. A callback would be more straight-forward, but since msg.c sits at the bottom of the lock hierarchy (it's used by virtually everything), this would probably be a nightmare. A ring buffer will be simpler and more predictable in the long run. We allocate new memory for each ringbuffer entry, which is probably a bit expensive. We could try to be clever and somehow pack the data directly into the buffer, but I felt like this wouldn't be worth the complexity. You'd have to copy the data a bunch of times anyway. I'm hoping that we can get away with using the ringbuffer mechanism for low frequency important messages only (and not e.g. for high volume debug messages), so the cost doesn't matter that much. A ringbuffer has a simple, single log level. I considered allowing --msglevel style per-prefix configuration for each ringbuffer, but that would have been pretty complicated to implement, and wouldn't have been that useful either.
2014-01-16 20:26:31 +00:00
void mp_msg_log_buffer_destroy(struct mp_log_buffer *buffer);
struct mp_log_buffer_entry *mp_msg_log_buffer_read(struct mp_log_buffer *buffer);
player: remove mechanisms for better logging with repl.lua As preparation for making repl.lua part of the core (maybe), add some mechanisms which are supposed to improve its behavior. Add a silent mode. Calling mpv_request_log_messages() with the log level name prefixed with "silent:" will disable logging from the API user's perspective. But it will keep the log buffer, and record new messages, without returning them to the user. If logging is enabled again by requesting the same log level without "silent:" prefix, the buffered log messages are returned to the user at once. This is not documented, because it's far too messy and special as that I'd want anyone to rely on this behavior, but it will be perfectly fine for an internal script. Another thing is that we record early startup messages. The goal is to make the repl.lua script show option and config parsing file errors. This works only with the special "terminal-default" log level. In addition, reduce the "terminal-default" capacity to only 100 log messages. If this is going to be enabled by default, it shouldn't use too much resources.
2019-11-17 23:44:12 +00:00
void mp_msg_log_buffer_set_silent(struct mp_log_buffer *buffer, bool silent);
msg: add a mechanism to output messages to a ringbuffer Until now, mp_msg output always went to the terminal. There was no way to grab the stream of output messages. But this will be needed by various future changes: Lua scripts, slave mode, client library... This commit allows registering a ring buffer. A callback would be more straight-forward, but since msg.c sits at the bottom of the lock hierarchy (it's used by virtually everything), this would probably be a nightmare. A ring buffer will be simpler and more predictable in the long run. We allocate new memory for each ringbuffer entry, which is probably a bit expensive. We could try to be clever and somehow pack the data directly into the buffer, but I felt like this wouldn't be worth the complexity. You'd have to copy the data a bunch of times anyway. I'm hoping that we can get away with using the ringbuffer mechanism for low frequency important messages only (and not e.g. for high volume debug messages), so the cost doesn't matter that much. A ringbuffer has a simple, single log level. I considered allowing --msglevel style per-prefix configuration for each ringbuffer, but that would have been pretty complicated to implement, and wouldn't have been that useful either.
2014-01-16 20:26:31 +00:00
options: change --msg-level option Make it accept "," as separator, instead of only ":". Do this by using the key-value-list parser. Before this, the option was stored as a string, with the option parser verifying that the option value as correct. Now it's stored pre-parsed, although the log levels still require separate verification and parsing-on-use to some degree (which is why the msg-level option type doesn't go away). Because the internal type changes, the client API "native" type also changes. This could be prevented with some more effort, but I don't think it's worth it - if MPV_FORMAT_STRING is used, it still works the same, just with a different separator on read accesses.
2015-02-06 15:48:52 +00:00
int mp_msg_find_level(const char *s);
msg: move special declarations to msg_control.h While almost everything uses msg.h, the moved definitions are rarely needed by anything.
2014-01-16 20:24:39 +00:00
Add some missing "const"s The one in msg.c was mistakenly removed with commit e99a37f6. I didn't actually test the change in ao_sndio.c (but obviously "ap" shouldn't be static).
2014-10-10 11:44:08 +00:00
extern const char *const mp_log_levels[MSGL_MAX + 1];
fix -Wduplicate-decl-specifier warnings with clang
2014-10-09 19:51:10 +00:00
extern const int mp_mpv_log_levels[MSGL_MAX + 1];
msg: expose log level names
2014-01-16 20:34:47 +00:00
msg: move special declarations to msg_control.h While almost everything uses msg.h, the moved definitions are rarely needed by anything.
2014-01-16 20:24:39 +00:00
#endif