libuv selector?

[machty]

Would it ever make sense to implement a selector that delegates to libuv for all the cross-platform stuff? With the recent kqueue fix, this question, and the fact that I'm seeing murmurings that "File descriptors that refer to files cannot be monitored with epoll.", I wonder if it wouldn't be make sense to reuse what's already been built. I can also imagine the "market" responding positively to the fact that Async Ruby supports the some IO backend that drives Node. What do you think?

Update: Hmm, looks like libuv is dragging their feet on implementing io_uring

[ioquatix]

I would be fine with having an alternative backend using libuv, libev and so on. The value of libuv is that it covers quite a lot of functionality and is will tested/designed.

That being said, I think we will ultimately get better performance by designing bespoke schedulers. So, not sure if the effort is worth it. We've used NIO4r for a long time and it's been rock solid for network IO, so we can do it, it does work, and we do get great performance.

The biggest short term milestone for us is solid io_uring support. The kernel still has a few bugs which prevent us from using it by default but soon (Linux 5.17) we can roll it out by default and I'm personally keen to throw all the effort behind making this the fast path.

[machty]

I see murmurings that the next Ubuntu LTS coming out in April will be based on 5.15, so unfortunately that'll miss the io_uring bugfixes, which also mean's Heroku's next stack (based on Ubuntu LTS) will also miss it for 2 years. Oh well, there's always Heroku's container stack for the folk who need it.

edit: Heroku's kernel actually seems to still be on 4.4.x, even for Ubuntu 20 stack, so Heroku apps will probably have a wait a very long time to use io_uring

[ioquatix]

@schneems is there anything we can do about that?