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

40 lines
1.3 KiB
C
Raw 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);
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: 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);
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