That does seem useful. But wouldn't you want to put this into a library that falls back to a thread pool approach on older kernels? And in that case, it seems like the application doesn't particularly care what the underlying implementation is? Since it's not built around asynchronous execution it just calls some function that blocks until the CQ is complete. This appears to be what the golang runtime will have to do.
>And with the 5.7 changes you can do polling + buffer selection + reading for any number of sockets with a single syscall
Thank you, this is very close was what I was looking for. (It hasn't made its way into the manpages yet)
That was mostly meant as an example of the more general case where using io-uring can reduce overhead of any kind of IO operation, even when they're not the primary focus of your application.
The point is that yes, io-uring is great for event-based, asynchronous libraries. But even traditional synchronous code can make significant gains by switching to it. As the article hints with its package name: io-uring is the one ring to bind them all.
> This appears to be what the golang runtime will have to do.
The go standard library can tie io-uring into its goroutine scheduler. When doing IO it suspends the green thread, submits the work to IO uring and polls the completion queue of the ring when looking for tasks that need to be woken up.
That does seem useful. But wouldn't you want to put this into a library that falls back to a thread pool approach on older kernels? And in that case, it seems like the application doesn't particularly care what the underlying implementation is? Since it's not built around asynchronous execution it just calls some function that blocks until the CQ is complete. This appears to be what the golang runtime will have to do.
>And with the 5.7 changes you can do polling + buffer selection + reading for any number of sockets with a single syscall
Thank you, this is very close was what I was looking for. (It hasn't made its way into the manpages yet)