3 ms·

Virtual threads are nice but they don't cover the same use cases as async and coroutines. Loom will make embarrassingly parallel workloads seamless but it won't

• mping 4y ago
  As I understand it, structured concurrency is part of the same deliverable, tracked in this JEP: https://openjdk.org/jeps/428 https://openjdk.org/jeps/428 Here's the example from the JEP: Response handle() throws ExecutionException, InterruptedException { try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { Future<String> user = scope.fork(() -> findUser()); Future<Integer> order = scope.fork(() -> fetchOrder()); scope.join(); // Join both forks scope.throwIfFailed(); // ... and propagate errors // Here, both forks have succeeded, so compose their results return new Response(user.resultNow(), order.resultNow()); } }
  • jayd16 4y ago
    I'm aware of the JEP. I said "as seen in this very release" after all. I don't see the advantage to this over async/await style programming. I think you'll see very similar error cases with unobserved exceptions and such. The advantage is that the method signature is indistinguishable from a blocking method. The subtle difference is that scopes close within a method where as async tasks can continue. I suppose you could see an even worse coloring where scopes and futures are used in half the methods instead of async. I'm trying to wrap my head around how this would play out if you were attempting to write a GUI or something where the pattern is a single main thread. I suppose it would work just fine and look very similar to async style programming but with a lot more code one tab to the right.
    • didibus 4y ago
      I've not normally seen people say async/await is a form of structured concurency. As I understand, structured concurency mostly imply automatic cancellation and supervision that allows retry/restarts. Does async/await gives you that?
      • jayd16 4y ago
        Automatic? I suppose not. But excuse me, I'm just comparing the APIs for a specific use case. I didn't mean to call them the same thing.
        • didibus 4y ago
          The additional features of structured concurency affect the API though, because you need to introduce scopes of supervision/cancellation/retries. If any async operation fails, at what level up the waiting chain do you want to cancel all other concurent tasks under it and retry the entire async flow? So you need the APIs/syntax to have ways to define these scope of cancellation/retries. As I understand, this is why it is called "structured", it refers to similar "structured" programming that introduced lexically scope restricted procedures, conditionals and loops. Edit: Also, just want to point out that you shouldn't get mixed up between async/await and future/promise. Async/await often uses future/promise, but don't necessarily have too. But future/promise is an async API that existed before async/await, and supports threaded concurency just fine. You can use future/promise in Java with both threads or virtual threads. Using it with virtual threads won't color functions because at any time you can block on a future/promise and extract the value, so it's possible to go from a future/promise returning function to one that doesn't return a future/promise.
          • jayd16 4y ago
            As far as defining scope goes, C# gets away with unchecked exceptions. Exceptions just bubble up naturally. Task scope is more implicit in syntax but scheduling Context is used in a similar way to scopes. The difference is context is usually inferred instead of explicitly defined at every use.
• vips7L 4y ago
  There’s another JEP for structured concurrency. https://bugs.openjdk.org/browse/JDK-8277129 https://bugs.openjdk.org/browse/JDK-8277129