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.
This commit is contained in:
wm4 2014-10-28 14:46:55 +01:00
parent 0c0ff638a3
commit 98356b81b4
1 changed files with 6 additions and 5 deletions

View File

@ -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 * overflow and silently discard further events. If this happens, making
* asynchronous requests will fail as well (with MPV_ERROR_EVENT_QUEUE_FULL). * 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 * Only one thread is allowed to call this on the same mpv_handle at a time.
* if more than one thread calls this, but it will cause race conditions in * The API won't complain if more than one thread calls this, but it will cause
* the client when accessing the shared mpv_event struct. Note that most other * race conditions in the client when accessing the shared mpv_event struct.
* API functions are not restricted by this, and no API function internally * Note that most other API functions are not restricted by this, and no API
* calls mpv_wait_event(). * 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 * @param timeout Timeout in seconds, after which the function returns even if
* no event was received. A MPV_EVENT_NONE is returned on * no event was received. A MPV_EVENT_NONE is returned on