5 ms·
Briefly, that a thread cannot escape a scope. All threads must be joined before leaving the scope. Some resources: https://wiki.openjdk.java.net/display/loom/
by jacques_chester 6y ago
Briefly, that a thread cannot escape a scope. All threads must be joined before leaving the scope.
Some resources:
https://wiki.openjdk.java.net/display/loom/Structured+Concurrency https://wiki.openjdk.java.net/display/loom/Structured+Concur...
https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html#structured-concurrency https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2....
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
- thu2111 6y agoNot exactly. That's the programming rule for structured concurrency which is a very simple bit of logic added on to the ExecutorService class. Loom itself is just about making threads super cheap/fast. You can use new cheap threads in exactly the same way as normal and nothing will complain. You can also use structured concurrency with old threads, and again, nothing will complain. And you don't need Java support for structured concurrency. You could implement it today with some wrapper classes.
- jacques_chester 6y agoNo, not exactly. Thus ever the fate of tl;drs. The discussion further down about "scope variables" foreshadows making structured concurrency more strongly, directly supported by the language's runtime: > What about inheritance? Because SVs are immutable, and because structured concurrency also gives us a syntax-confined thread lifetime, SV inheritance fits structured concurrency like a glove
- thu2111 6y agoScoped vars are nice but I never saw anyone claim they're a required part of structured concurrency. They're mostly an optimisation over ThreadLocal.
- jacques_chester 6y agoI never said required.