3 ms·

Bit awkward timing with project loom looming in the future

• mooreds 4y ago
  Aren't loom and nio somewhat orthogonal? Agreed that the threading parts of this project might need to be looked at/reworked when loom is released. More discussion here: https://www.reddit.com/r/java/comments/nsb2w1/will_loom_render_java_nio_useless/ https://www.reddit.com/r/java/comments/nsb2w1/will_loom_rend...
  • NoBreakfirst 4y ago
    I haven’t try loom yet but the thread api looks untouched ? That was my understanding. But yeah … opening this project I was scanning for Java 19 / loom reference
    • mooreds 4y ago
      Fair enough. I added a PR to clear up why Loom isn't used: https://github.com/FusionAuth/java-http/pull/1/files https://github.com/FusionAuth/java-http/pull/1/files
  • MrBuddyCasino 4y ago
    Isn’t the point of project loom that you can just use pseudo-blocking IO using the traditional thread API on a fiber scheduler, making NIO in application code obsolete?
  • Scarbutt 4y ago
    Aren't loom and nio somewhat orthogonal? No, they are virtually the same abstraction.
    • brokenwren 4y ago
      Actually, Loom is about threading and helps support NIO. You'll still need Selectors, Channels, and ByteBuffers with Loom, you'll just be able to pass off the parsing and handling to a Fiber. You might be able to get away with doing the IO blocking with Fibers, but it likely won't scale. Non-blocking IO is still way faster at the OS level so my guess is that Loom will simply replace 10-20 lines of code in java-http and the majority of the IO will be the same.
      • spullara 4y ago
        All blocking IO when run in fibers will be potentially non-blocking. That is literally the point of Loom. Also, non-blocking IO is almost never faster than blocking IO but you can handle way more connections with it. You use NIO for scale not for latency. Due to fairness concerns you will also want to hand off heavy computation to native threads vs fibers. Fibers are for IO.
        • brokenwren 4y ago
          I don't think this is accurate. The Loom documentation says specifically that it is a concurrency model to replace native threads with fibers. It says very little about non-blocking IO, except that it is a use-case that it assists with: https://openjdk.org/jeps/425 https://openjdk.org/jeps/425 The NIO section covers a bit about how the fibers release the channels, but the OS will not know that. Non-blocking IO is about interrupts at the hardware level that let the application code know when bytes are ready to be read or written. Fibers help by fanning out the work, but they don't replace this concept.
          • throwawayisize 4y ago
            FTA, it's pretty clear. Typically, a virtual thread will unmount when it blocks on I/O or some other blocking operation in the JDK, such as BlockingQueue.take(). When the blocking operation is ready to complete (e.g., bytes have been received on a socket), it submits the virtual thread back to the scheduler, which will mount the virtual thread on a carrier to resume execution. The mounting and unmounting of virtual threads happens frequently and transparently, and without blocking any OS threads. For example, the server application shown earlier included the following line of code, which contains calls to blocking operations: response.send(future1.get() + future2.get()); These operations will cause the virtual thread to mount and unmount multiple times, typically once for each call to get() and possibly multiple times in the course of performing I/O in send(...). > Non-blocking IO is about interrupts at the hardware level This isn't relevant. We only care from the perspective of userspace.