Automatic fallback to Epoll if io_uring is not available

[00-kat]

This should be a discussion, but I can't figure out how to make one.

It would be nice if libxev automatically tried the Epoll backend on Linux if the call to io_uring_setup() fails.

A real-life scenario where io_uring might not be available but Epoll might be is if the kernel.io_uring_disabled sysctl was disabled, which would result in io_uring_setup() setting errno to EPERM (as far as I can tell, the Zig wrapper does not translate this to an error union). I don't know of any distribution which does this by default other than Arch Linux if you use the hardened kernel.

A possible downside (and the main reason why this should be a discussion) is that both io_uring and Epoll backends are compiled into the binary even if only one is used, which is antithetical to the point "Tree Shaking" mentioned in the README.

[mitchellh]

I agree this is a major issue.

I think the right path forward is to implement a vtable-based Xev. So in addition to the static dispatch we have already, introduce something like a RuntimeXev or DynamicXev that takes a vtable pointer. This would follow a pattern similar to Zig's std.mem.Allocator.

Then, we could write a detector that returned the proper RuntimeXev for your platform... i.e. something like DetectXev.init(). To address tree-shaking, you'd only get multiple backends compiled in if you used the dynamic dispatch Xev. If you used a static dispatch one directly you'd still get tree shaking.

This is actually something Ghostty really needs because for packaging purposes we probably want our packages to be portable across kernel versions.

[mbekkomo]

io_uring is also not available in Android Afair.

[Corendos]

Just hopping to give my 2 cents because we had the issue at ZML 👀

I think the right path forward is to implement a vtable-based Xev

Does it really need to be a vtable ? vtables are nice when you don't know beforehand all the implementations (and allows other to implement the interface) but in the case of xev we already know the different backends on linux, epoll and io_uring. So we could probably just have a tagged union and avoid the cost of indirection no ?

[mitchellh]

That’s true. For Linux the fallback path is well known so we can use static dispatch. I actually wonder if that’s faster than a vtable on modern CPU architectures. I suppose a conditional that’s almost always the same probably is.

[voidastro4]

io_uring is the source of multiple vulnerabilities, Google recommends turning it off. https://www.phoronix.com/news/Google-Restricting-IO_uring

ghostty is nonfunctional.

[00-kat]

Off-topic, but

ghostty is nonfunctional

@voidastro4 maybe check out ghostty-org/ghostty#3267 (comment).