<div dir="ltr"><div dir="ltr">Is there any way to see the code of the prototypes?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 23 сент. 2022 г. в 16:42, Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 23/09/2022 13:10, Ilya Korennoy wrote:<br>
> Hello!<br>
><br>
> I am studying Project Loom and thinking about its integration with <br>
> io_uring, and I wanted to clarify a couple of questions.<br>
><br>
> I've studied the implementation of Socket in Java 19 and the <br>
> integration of epoll and Loom. The idea is clear, Loom thread tries to <br>
> read from the socket if it fails it goes to sleep, when epoll returns <br>
> an event Loom thread wakes up and tries to read again. The epoll <br>
> readiness model integrates well with Loom.<br>
><br>
> Io_uring has a different model: completion. The interface itself does <br>
> the I/O, then returns the result. I understand how to integrate <br>
> callback-based systems like CompletableFuture or Kotlin Coroutines <br>
> with this model, but I have absolutely no idea how to make integration <br>
> with Loom.<br>
><br>
> I have the following questions:<br>
><br>
> In the current socket implementation, when we need to stop a thread <br>
> (the socket is not ready) it is saved in Map, where the key is the fd <br>
> of that socket. When epoll returns the result we take the thread out <br>
> of Map and keep it running.<br>
> In case of io_uring we can save Callback (CompletableFuture or Kotlin <br>
> Continuation), but what would you save in case of Loom? Thread is not <br>
> suitable since we need to send the result that io_uring returned.<br>
<br>
We don't have the support for io_uring in the repo at this time. For the <br>
socket code, one of the prototypes uses IORING_OP_POLL_ADD and <br>
IORING_OP_POLL_REMOVE rather than IORING_OP_READ/IORING_OP_WRITE. This <br>
avoids most of the complexity, worker pool issues, and needing to keep <br>
off-heap memory alive for the duration of the network ops. The work for <br>
file ops does bring in some of the complexity that you are concerned <br>
about but they are mostly non-interruptible so we can't need to be <br>
concerned with cancellation.<br>
<br>
-Alan<br>
</blockquote></div></div>