Hi, On 23.04.19 22:31, Jens Axboe wrote: > On 4/23/19 1:06 PM, Stefan Bühler wrote: >> I have one other question: is there any way to cancel an IO read/write >> operation? I don't think closing io_uring has any effect, what about >> closing the files I'm reading/writing? (Adding cancelation to kiocb >> sounds like a non-trivial task; and I don't think it already supports it.) > > There is no way to do that. If you look at existing aio, nobody supports > that either. Hence io_uring doesn't export any sort of cancellation outside > of the poll case where we can handle it internally to io_uring. > > If you look at storage, then generally IO doesn't wait around in the stack, > it's issued. Most hardware only supports queue abort like cancellation, > which isn't useful at all. > > So I don't think that will ever happen. > >> So cleanup in general seems hard to me: do I have to wait for all >> read/write operations to complete so I can safely free all buffers >> before I close the event loop? > > The ring exit waits for IO to complete already. I now understand at least how that part is working; io_ring_ctx_wait_and_kill calls wait_for_completion(&ctx->ctx_done), which only completes after all references are gone; each pending job keeps a reference. But wait_for_completion is not interruptible; so if there are "stuck" jobs even root can't kill the task (afaict) anymore. Once e.g. readv is working on pipes/sockets (I have some local patches here for that), you can easily end up in a situation where a socketpair() or a pipe() is still alive, but the read will never finish (I can trigger this problem with an explicit close(uring_fd), not sure how to observe this on process exit). For a socketpair() even both ends could be kept alive by never ending read jobs. Using wait_for_completion seems like a really bad idea to me; this is a problem for io_uring_register too. cheers, Stefan
