Wouldn't io_uring complexity be hidden behind the async io abstraction? Would the file manager even have to bother what underlying mechanism provides the async IO interface with the kernel? (epoll, kqueue, io_uring, etc)
Are there know ways that io_uring would leak through such an abstraction?
I was assuming the file manager would have to include the code for the async abstraction. But of course it could be just part of the async runtime / standard library. Still, a file manager doesn't seem like it would really need the ability to be so massively concurrent.
Almost every UI framework out there is single-threaded and has facilities to help offloading such tasks into the background. Usually, to a worker thread pool. It's a bit fiddly, especially in a non-managed language that doesn't protect from dumb mistakes, but it can be easily done.
io_uring is for use cases where the context switch overhead of system calls starts to matter. While async I/O can be justified for U/I programming, it's safe to say that a file manager won't ever benefit from io_uring.
What advantage does thread pool + io_uring have over just thread pool?
Unless you have millions of CPU cores and therefore many downscaling/encoding/highlighting tasks starting/finishing every second, I still don't see what io_uring brings to the table.
Running tasks in the background does NOT require io_uring.
