summaryrefslogtreecommitdiffstats
path: root/libmpv
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2018-05-10 12:41:01 +0200
committerwm4 <wm4@nowhere>2018-05-24 19:56:34 +0200
commit005d3bc81a86dddf458c0d19142815687a303877 (patch)
treecbda4116d6e54ccfccda5d0d739762d7a4d36ba6 /libmpv
parent95c4f0f7698879f28cec7159f03fc7fd211bcff7 (diff)
downloadmpv-005d3bc81a86dddf458c0d19142815687a303877.tar.bz2
mpv-005d3bc81a86dddf458c0d19142815687a303877.tar.xz
client API: clarify asynchronous call ordering non-guarantees
Both asynchronous and synchronous calls used to be put into the core's dispatch queue. Also, asynchronous calls were actually synchronous, just without forcing a wait on the client's thread. This meant that both kinds of calls were always strictly ordered. A longer time ago, synchronous calls were changed to simply lock the core. This could possibly lead to reordering. Recently, some commands were changed to run on worker threads, which made the order even looser. Also remove another now incorrect doxygen comment regarding async commands.
Diffstat (limited to 'libmpv')
-rw-r--r--libmpv/client.h9
1 files changed, 3 insertions, 6 deletions
diff --git a/libmpv/client.h b/libmpv/client.h
index d2a9ebfbac..b276c54390 100644
--- a/libmpv/client.h
+++ b/libmpv/client.h
@@ -107,8 +107,9 @@ extern "C" {
* careful not accidentally interpret the mpv_event->reply_userdata if an
* event is not a reply. (For non-replies, this field is set to 0.)
*
- * Currently, asynchronous calls are always strictly ordered (even with
- * synchronous calls) for each client, although that may change in the future.
+ * Asynchronous calls may be reordered in arbitrarily with other synchronous
+ * and asynchronous calls. If you want a guaranteed order, you need to wait
+ * until asynchronous calls report completion before doing the next call.
*
* Multithreading
* --------------
@@ -969,10 +970,6 @@ int mpv_command_string(mpv_handle *ctx, const char *args);
* MPV_EVENT_COMMAND_REPLY event. (This event will also have an
* error code set if running the command failed.)
*
- * This has nothing to do with the "async" command prefix, although they might
- * be unified in the future. For now, calling this API means that the command
- * will be synchronously executed on the core, without blocking the API user.
- *
* * Safe to be called from mpv render API threads.
*
* @param reply_userdata the value mpv_event.reply_userdata of the reply will