Hi Jens,
On 2020/7/31 上午11:57, Jens Axboe wrote:
> Then why not just make the sqe-less timeout path flush existing requests,
> if it needs to? Seems a lot simpler than adding odd x2 variants, which
> won't really be clear.
>
Flushing the requests will access and modify the head of submit queue, that
may race with the submit thread. I think the reap thread should not touch
the submit queue when IORING_FEAT_GETEVENTS_TIMEOUT is supported.
> Chances are, if it's called with sq entries pending, the caller likely
> wants those submitted. Either the caller was aware and relying on that
> behavior, or the caller is simply buggy and has a case where it doesn't
> submit IO before waiting for completions.
>
That is not true when the SQ/CQ handling are split in two different threads.
The reaping thread is not aware of the submit queue. It should only wait for
completion of the requests, such as below:
submitting_thread: reaping_thread:
io_uring_get_sqe()
io_uring_prep_nop()
io_uring_wait_cqe_timeout2()
io_uring_submit()
woken if requests are completed or timeout
And if the SQ/CQ handling are in the same thread, applications should use the
old API if they do not want to submit the request themselves.
io_uring_get_sqe
io_uring_prep_nop
io_uring_wait_cqe_timeout
> Hence I really don't think that's a big deal, and even arguably the right
> thing to do.
