Project Loom and io_uring integration
Ilya Korennoy
korennoy.ilya at gmail.com
Fri Sep 23 14:16:06 UTC 2022
Is there any way to see the code of the prototypes?
пт, 23 сент. 2022 г. в 16:42, Alan Bateman <Alan.Bateman at oracle.com>:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220923/b5a070c7/attachment.htm>
More information about the loom-dev
mailing list