command: add infrastructure for async commands

This enables two types of command behavior:

1. Plain async behavior, like "loadfile" not completing until the file
   is fully loaded.
2. Running parts of the command on worker threads, e.g. for I/O, such as
   "sub-add" doing network accesses on a thread while the core
   continues.

Both have no implementation yet, and most new code is actually inactive.
The plan is to implement a number of useful cases in the following
commits.

The most tricky part is handling internal keybindings (input.conf) and
the multi-command feature (concatenating commands with ";"). It requires
a bunch of roundabout code to make it do the expected thing in
combination with async commands.

There is the question how commands should be handled that come in at a
higher rate than what can be handled by the core. Currently, it will
simply queue up input.conf commands as long as memory lasts. The client
API is limited by the size of the reply queue per client. For commands
which require a worker thread, the thread pool is limited to 30 threads,
and then will queue up work in memory. The number is completely
arbitrary.

1 files changed, 21 insertions, 3 deletions

diff --git a/player/command.h b/player/command.h
index b6ccffe80f..9e385dbc16 100644
--- a/player/command.h
+++ b/player/command.h
@@ -20,6 +20,8 @@
 
 #include <stdbool.h>
 
+#include "libmpv/client.h"
+
 struct MPContext;
 struct mp_cmd;
 struct mp_log;
@@ -43,12 +45,28 @@ struct mp_cmd_ctx {
     bool bar_osd;       // OSD bar requested
     bool seek_msg_osd;  // same as above, but for seek commands
     bool seek_bar_osd;
-    // Return values
+    // Return values (to be set by command implementation, read by the
+    // completion callback).
     bool success;       // true by default
-    struct mpv_node *result;
+    struct mpv_node result;
+    // Command handlers can set this to false if returning from the command
+    // handler does not complete the command. It stops the common command code
+    // from signaling the completion automatically, and you can call
+    // mp_cmd_ctx_complete() to invoke on_completion() properly (including all
+    // the bookkeeping).
+    /// (Note that in no case you can call mp_cmd_ctx_complete() from within
+    // the command handler, because it frees the mp_cmd_ctx.)
+    bool completed;     // true by default
+    // This is managed by the common command code. For rules about how and where
+    // this is called see run_command() comments.
+    void (*on_completion)(struct mp_cmd_ctx *cmd);
+    void *on_completion_priv; // for free use by on_completion callback
 };
 
-int run_command(struct MPContext *mpctx, struct mp_cmd *cmd, struct mpv_node *res);
+void run_command(struct MPContext *mpctx, struct mp_cmd *cmd,
+                 void (*on_completion)(struct mp_cmd_ctx *cmd),
+                 void *on_completion_priv);
+void mp_cmd_ctx_complete(struct mp_cmd_ctx *cmd);
 char *mp_property_expand_string(struct MPContext *mpctx, const char *str);
 char *mp_property_expand_escaped_string(struct MPContext *mpctx, const char *str);
 void property_print_help(struct MPContext *mpctx);