can there be a race between a read or write operation and a close

[FrankReh]

If a read or write operation is in-flight, has it incremented an entry in the file descriptor table?, so if a close for the same file descriptor were to come to the same submission queue, or a different one, or as a synchronous close(2) call, will the file descriptor be kept open until the in-flight read or write is done?

[FrankReh]

I understand the risk of a race if the sqe had not been flushed to the device yet and a close for the same file descriptor made it to the kernel first though another mechanism. I'm curious whether once the enter call has returned so the submission queue has a been fully read, is it safe to allow a close for a related file descriptor to happen, on the same thread, or is it necessary to hold the close until the operation has completed?

[isilence]

io_uring resolves files (and takes refs) lazily, so you'd need to wait for completions or order close requests with reads/etc. (e.g. via links). In practice, files are eagerly resolved except for links and draining but that may change.

[FrankReh]

Ok. I don't like the answer, (lazy references are taken), but I'm very happy you could answer this so quickly. It means the code that's been in tokio-uring to block closing until all operations on the fd are complete is justified and I won't be lobbying to remove it.

Thank you!

Edit: Rather than say I didn't like the answer, I should have said I understand but was hoping for a different answer. Your uring device is awesome and we're lucky to have it.