Issue: io_uring_wait_cqe with no pending requests should return error instead of dead locking about liburing HOT 9 CLOSED

If multiple threads are waiting on the same cq ring, then they would both get woken up if an event is posted. They then have to ensure mutual exclusivity for reading the events and ring, of course.

from liburing.

We do return the number submitted, so if the function returns 0, nothing was submitted and we didn't wait for anything. I agree that's a bug in the application, but the return value is pretty clear.

Not quite sure I see the issue here, to be honest.

from liburing.

We do return the number submitted, so if the function returns 0, nothing was submitted and we didn't wait for anything.

I was talking about io_uring_wait_cqe instead of io_uring_submit_and_wait

#include <stdio.h>
#include "liburing.h"

int main()
{
	struct io_uring ring;
	struct io_uring_cqe *cqe;
	int ret;

	ret = io_uring_queue_init(8, &ring, 0);
	if (ret) {
		printf("ring setup failed\n");
		return 1;
	}

	return io_uring_wait_cqe(&ring, &cqe); // dead lock
}

from liburing.

Sorry my bad, my eyes were tired. I don't think it's a given that doing io_uring_wait_cqe() on an empty queue is a bug. It could be that the application has multiple threads sharing that ring, and someone else will queue IO on it. The scenario you outline isn't a deadlock, it's interruptible sleep. So you can wake the application, if you need/want to.

from liburing.

Is liburing thread safe? Ok I see.

So can we have io_uring_pending_requests that get the number of unhandled (running and in cqe) requests?

from liburing.

The kernel side has the protection it needs, if you want multiple threads filling in and updating the SQ ring, then you need to have your own synchronization in userspace. But it's doable.

It's not possible to implement io_uring_pending_requests() without adding additional tracking on the kernel side. SQEs are consumed before the IO is complete, so we'd need an additional counter to do that. Nothing tracks the count of requests that are inflight, but haven't yet completed and produced a CQE.

from liburing.

Ok. Thanks for your explaination. I wonder what will happen if multiple threads are waiting the same ring though.

from liburing.

@axboe I notice you said

It could be that the application has multiple threads sharing that ring, and someone else will queue IO on it.

Is that means if I already call io_uring_wait_cqe and is blocked because there is no available cqe, I can submit a new sqe on another thread, and if it done, the io_uring_wait_cqe will return the cqe about the new sqe

from liburing.

@axboe I notice you said

我注意到你说

It could be that the application has multiple threads sharing that ring, and someone else will queue IO on it.这可能是因为应用程序有多个线程共享该环，而其他线程将在其上对 IO 进行排队。

Is that means if I already call io_uring_wait_cqe and is blocked because there is no available cqe, I can submit a new sqe on another thread, and if it done, the io_uring_wait_cqe will return the cqe about the new sqe

这是否意味着如果我已经调用 io uring wait cqe 并且因为没有可用的 cqe 而被阻塞，我可以在另一个线程上提交一个新的 sqe，如果这样做了，io uring wait cqe 将返回关于新 sqe 的 cqe

@axboe I notice you said

It could be that the application has multiple threads sharing that ring, and someone else will queue IO on it.

Is that means if I already call io_uring_wait_cqe and is blocked because there is no available cqe, I can submit a new sqe on another thread, and if it done, the io_uring_wait_cqe will return the cqe about the new sqe

I have the same doubts，I tested this and it works on one machine, but not on another.

from liburing.