6 ms·

I'm not really grokking the code sample on their frontpage. What is it doing? Explain it like I am a Java developer with 18 years of experience.

Tainnor 3y ago
It's referencing other variables and functions that aren't defined in that snippet. Presumably you can somewhat guess what it's trying to do (call a function for each element of the response), but it doesn't seem like a very good example. I also don't quite understand how this utilises virtual threads effectively, isn't the code still adding the elements of the list one at a time instead of concurrently?
- mikmoila 3y ago
  One at a time, not concurrently.
  - Tainnor 3y ago
    so what's the point? we can already write blocking code. The reason why people want to use reactive frameworks is because they don't want to block threads just because some I/O is happening.
    - mikmoila 3y ago
      Nima uses virtual threads where blocking call blocks only the current virtual thread but not the underlying carrier-thread, which can run another virtual thread while waiting i/o to complete.
      - Tainnor 3y ago
        But in this example, the entire code is still blocking because it has to wait for one call of "callRemote" to complete while waiting for the next one to be executed. So I don't get the point. for (int i = 0; i < count; i++) { resp.add(callRemote(client)); }
        xcv123 3y ago
        That entire section is running on a virtual thread, which is scheduled on a platform (OS) thread. While it blocks for each callRemote invocation the platform thread is free to process other virtual threads. https://docs.oracle.com/en/java/javase/20/core/virtual-threads.html#GUID-DC4306FC-D6C1-4BCC-AECE-48C32C1A8DAA https://docs.oracle.com/en/java/javase/20/core/virtual-threa...
        Tainnor 3y ago
        Yeah but if for some reason, no other (or few other) request is coming in concurrently, then the CPU will just sit by idly. I don't understand why you wouldn't issue the "callRemote" calls concurrently, that seems like it's missing the point of writing non-blocking code.
        xcv123 3y ago
        Exactly. That's the point. It is beneficial only when you have a huge number of requests relative to the number of platform threads. The idea is that you can map a million of these virtual threads on to a small number of platform threads, and the JVM will schedule the work for you, to achieve maximum throughput without needing to write any complicated code. Virtual threads are for high throughput on concurrent blocking requests. EDIT: the sequential calls to "callRemote" still process in sequence, blocking on each call. Don't get confused there. But the overall HTTP request itself is running on a virtual thread and does not block other HTTP requests while waiting for the callRemote invocations to complete.
        Tainnor 3y ago
        > EDIT: the sequential calls to "callRemote" still process in sequence, blocking on each call. Don't get confused there. But the overall HTTP request itself is running on a virtual thread and does not block other HTTP requests while waiting for the callRemote invocations to complete. Yeah I got that. But then the use case seems to be much narrower, because not every scenario is one where many concurrent requests come in at the same time. If you write non-blocking code you'll get high throughput no matter the number of requests. Ok, maybe non-blocking code is harder to write (and I don't think it's actually that hard if you use, say, Kotlin coroutines), but honestly this seems to me like something that developers should learn eventually anyway. Or maybe it's me being weird. But I remember 10 years ago when node.js was being hyped for being "fast" because it was "async" and now suddenly using threads and blocking operations is again all the rage now.
    - geodel 3y ago
      Point is exactly you can block because blocking is cheap with virtual thread and can have 100's of thousand block calls with exhausting all system resources. VT takes few KBs of memory instead of few MBs of memory, so plentiful of VT is a feature. With this one can write plain blocking code get benefit of async scalability but with simple APIs structure and debuggable sync code.
mikmoila 3y ago
"callRemote" simulates a blocking outbound http-call.

Tainnor 3y ago

It's referencing other variables and functions that aren't defined in that snippet. Presumably you can somewhat guess what it's trying to do (call a function for each element of the response), but it doesn't seem like a very good example. I also don't quite understand how this utilises virtual threads effectively, isn't the code still adding the elements of the list one at a time instead of concurrently?

mikmoila 3y ago
One at a time, not concurrently.
- Tainnor 3y ago
  so what's the point? we can already write blocking code. The reason why people want to use reactive frameworks is because they don't want to block threads just because some I/O is happening.
  - mikmoila 3y ago
    Nima uses virtual threads where blocking call blocks only the current virtual thread but not the underlying carrier-thread, which can run another virtual thread while waiting i/o to complete.
    - Tainnor 3y ago
      But in this example, the entire code is still blocking because it has to wait for one call of "callRemote" to complete while waiting for the next one to be executed. So I don't get the point. for (int i = 0; i < count; i++) { resp.add(callRemote(client)); }
      - xcv123 3y ago
        That entire section is running on a virtual thread, which is scheduled on a platform (OS) thread. While it blocks for each callRemote invocation the platform thread is free to process other virtual threads. https://docs.oracle.com/en/java/javase/20/core/virtual-threads.html#GUID-DC4306FC-D6C1-4BCC-AECE-48C32C1A8DAA https://docs.oracle.com/en/java/javase/20/core/virtual-threa...
        Tainnor 3y ago
        Yeah but if for some reason, no other (or few other) request is coming in concurrently, then the CPU will just sit by idly. I don't understand why you wouldn't issue the "callRemote" calls concurrently, that seems like it's missing the point of writing non-blocking code.
        xcv123 3y ago
        Exactly. That's the point. It is beneficial only when you have a huge number of requests relative to the number of platform threads. The idea is that you can map a million of these virtual threads on to a small number of platform threads, and the JVM will schedule the work for you, to achieve maximum throughput without needing to write any complicated code. Virtual threads are for high throughput on concurrent blocking requests. EDIT: the sequential calls to "callRemote" still process in sequence, blocking on each call. Don't get confused there. But the overall HTTP request itself is running on a virtual thread and does not block other HTTP requests while waiting for the callRemote invocations to complete.
        Tainnor 3y ago
        > EDIT: the sequential calls to "callRemote" still process in sequence, blocking on each call. Don't get confused there. But the overall HTTP request itself is running on a virtual thread and does not block other HTTP requests while waiting for the callRemote invocations to complete. Yeah I got that. But then the use case seems to be much narrower, because not every scenario is one where many concurrent requests come in at the same time. If you write non-blocking code you'll get high throughput no matter the number of requests. Ok, maybe non-blocking code is harder to write (and I don't think it's actually that hard if you use, say, Kotlin coroutines), but honestly this seems to me like something that developers should learn eventually anyway. Or maybe it's me being weird. But I remember 10 years ago when node.js was being hyped for being "fast" because it was "async" and now suddenly using threads and blocking operations is again all the rage now.
  - geodel 3y ago
    Point is exactly you can block because blocking is cheap with virtual thread and can have 100's of thousand block calls with exhausting all system resources. VT takes few KBs of memory instead of few MBs of memory, so plentiful of VT is a feature. With this one can write plain blocking code get benefit of async scalability but with simple APIs structure and debuggable sync code.

mikmoila 3y ago

"callRemote" simulates a blocking outbound http-call.