loop: don't call the hooks around blocking wait

The blocking invoke function is not meant to be called with any of the
loop context locks acquired so that it can actually run the invoke call
while blocking. Make this (and other blocking risks) clear in the
documentation.

Because it is not supposed to be called with any of the locks, we should
also not try to call the hooks (that implement the unlock/lock).

Fixes #4472
This commit is contained in:
Wim Taymans 2025-06-10 11:57:38 +02:00
parent 1139ab5966
commit 46dfa69f26
2 changed files with 5 additions and 6 deletions

View file

@ -119,8 +119,11 @@ struct spa_loop_methods {
* an object that has identity.
* \param size The size of data to copy.
* \param block If \true, do not return until func has been called. Otherwise,
* returns immediately. Passing \true does not risk a deadlock because
* the data thread is never allowed to wait on any other thread.
* returns immediately. Passing \true can cause a deadlock when
* the calling thread is holding the loop context lock. A blocking
* invoke should never be done from a realtime thread. Also beware
* of blocking invokes between 2 threads as you can easily end up
* in a deadly embrace.
* \param user_data An opaque pointer passed to func.
* \return `-EPIPE` if the internal ring buffer filled up,
* if block is \false, 0 if seq was SPA_ID_INVALID or

View file

@ -472,14 +472,10 @@ again:
if (block && queue->ack_fd != -1) {
uint64_t count = 1;
spa_loop_control_hook_before(&impl->hooks_list);
if ((res = spa_system_eventfd_read(impl->system, queue->ack_fd, &count)) < 0)
spa_log_warn(impl->log, "%p: failed to read event fd:%d: %s",
queue, queue->ack_fd, spa_strerror(res));
spa_loop_control_hook_after(&impl->hooks_list);
res = item->res;
}
else {