Closed mattrpav closed 1 year ago
I think adding kqueue support means I can test io_uring-like support functionality on my Mac ;-). Get the java bits right, then move the build to a Linux server for CI and integration testing.
I'm a Mac user too so I appreciate the sentiment, but the real challenge here is that kqueue, like select, epoll, etc. uses a pattern that indicates readiness for an I/O operation as opposed to completion like with io_uring. Implementing the nio_uring API on top of kqueue would require an entirely new abstraction layer, as well as a lot of new native code, that would all require additional maintenance to keep parity as we add more features.
Always open to suggestions and feedback, but I think it's best to hold off on a large feature like this for now; and just recommend using a docker container to test things. I'm still just one guy building it on the side of my 9-5. :)
This request goes a little deeper into the scope and purpose of this project, because the core intention here is to really do one thing well. I had some requests to add
java.nio.channels.Selector
functionality as a fallback on systems without io_uring, which brought up the same thought process. I personally feel like the responsibility of compatibility might be better placed on the shoulders of whatever system is using nio_uring. Wondering if you have any thoughts?