Project Loom and io_uring integration

[Alan Bateman]

On 23/09/2022 13:10, Ilya Korennoy wrote:
> Hello!
>
> I am studying Project Loom and thinking about its integration with 
> io_uring, and I wanted to clarify a couple of questions.
>
> I've studied the implementation of Socket in Java 19 and the 
> integration of epoll and Loom. The idea is clear, Loom thread tries to 
> read from the socket if it fails it goes to sleep, when epoll returns 
> an event Loom thread wakes up and tries to read again. The epoll 
> readiness model integrates well with Loom.
>
> Io_uring has a different model: completion. The interface itself does 
> the I/O, then returns the result. I understand how to integrate 
> callback-based systems like CompletableFuture or Kotlin Coroutines 
> with this model, but I have absolutely no idea how to make integration 
> with Loom.
>
> I have the following questions:
>
> In the current socket implementation, when we need to stop a thread 
> (the socket is not ready) it is saved in Map, where the key is the fd 
> of that socket. When epoll returns the result we take the thread out 
> of Map and keep it running.
> In case of io_uring we can save Callback (CompletableFuture or Kotlin 
> Continuation), but what would you save in case of Loom? Thread is not 
> suitable since we need to send the result that io_uring returned.

We don't have the support for io_uring in the repo at this time. For the 
socket code, one of the prototypes uses IORING_OP_POLL_ADD and 
IORING_OP_POLL_REMOVE rather than IORING_OP_READ/IORING_OP_WRITE. This 
avoids most of the complexity, worker pool issues, and needing to keep 
off-heap memory alive for the duration of the network ops. The work for 
file ops does bring in some of the complexity that you are concerned 
about but they are mostly non-interruptible so we can't need to be 
concerned with cancellation.

-Alan