|author||wm4 <wm4@nowhere>||2014-10-28 14:46:55 +0100|
|committer||wm4 <wm4@nowhere>||2014-10-28 20:30:11 +0100|
client API: clarify statement about thread-safety
The only reason for mpv_wait_event() not being thread-safe is that it returns a pointer to a mpv_event struct member in the mpv_handle context, which in turn is done for ABI-safety (user doesn't allocate or manage the struct), and to avoid the need additional memory management. Some users were interpreting this incorrectly.
1 files changed, 6 insertions, 5 deletions
diff --git a/libmpv/client.h b/libmpv/client.h
index 7f545866aa..8138b2ad5b 100644
@@ -1222,11 +1222,12 @@ int mpv_request_log_messages(mpv_handle *ctx, const char *min_level);
* overflow and silently discard further events. If this happens, making
* asynchronous requests will fail as well (with MPV_ERROR_EVENT_QUEUE_FULL).
- * Only one thread is allowed to call this at a time. The API won't complain
- * if more than one thread calls this, but it will cause race conditions in
- * the client when accessing the shared mpv_event struct. Note that most other
- * API functions are not restricted by this, and no API function internally
- * calls mpv_wait_event().
+ * Only one thread is allowed to call this on the same mpv_handle at a time.
+ * The API won't complain if more than one thread calls this, but it will cause
+ * race conditions in the client when accessing the shared mpv_event struct.
+ * Note that most other API functions are not restricted by this, and no API
+ * function internally calls mpv_wait_event(). This does not apply to concurrent
+ * calls of this function on different mpv_handles: these are always safe.
* @param timeout Timeout in seconds, after which the function returns even if
* no event was received. A MPV_EVENT_NONE is returned on