3 ms·

> putting aside the separate question of communication among threads But that's.. 99% of the problem. If you haven't solved that then you haven't solved anythi

> putting aside the separate question of communication among threads But that's.. 99% of the problem. If you haven't solved that then you haven't solved anything. Solving that is the point of Future systems, the m:n scheduling is just a nice cherry on top.

pron 3y ago
These features become orthogonal when the right primitives are there, and so there's no need for a "system" (other than the language/platform itself). Some of the communication problem is already addressed by other Loom features (https://openjdk.org/jeps/453 https://openjdk.org/jeps/453), and others will be addressed by future ones (like channels).
- avodonosov 3y ago
  BlockingQueue is a kind of channel already, what are you thinking to add? And to the main point, of course, Java has plenty of thread comrunioation possibilities, Loom just makes threads cheaper.
  - pron 3y ago
    > BlockingQueue is a kind of channel already, what are you thinking to add? The main difference between a channel and a BlockingQueue is that a channel can be closed, i.e. it allows one or both sides to signal the other that they're done producing/consuming. > And to the main point, of course, Java has plenty of thread comrunioation possibilities, Loom just makes threads cheaper. Definitely.
ye-olde-sysrq 3y ago
99% of which problem, though? IMO the whole point of Loom, and what I'm looking forward to, is code that looks like this: fooer.onCompletion(() -> System.out.println("yay")); fooer.onError(e -> System.out.println("o no")); fooer.foo(); // foo is some long operation can once again simply be: try { foo() S.o.p("yay"); } catch(Exception e) { S.o.p("o no"); } just like any college kid would've written 20 years ago in their CS 101 class in the chapter on exceptions. Many multi-threaded programs today don't even have a "communication among threads" problem. - they avoid it by simply not communicating between threads. They precompute work splits and then farm it out, and then gather up all the results. Consider HTTP servers or RPC handlers. A request is farmed out to them, they do a bunch of IO stuff to answer it, and then release their thread back to a pool. That's a huge use-case that gets materially improved right there. Look at what goroutines did for go programming.

pron 3y ago

These features become orthogonal when the right primitives are there, and so there's no need for a "system" (other than the language/platform itself). Some of the communication problem is already addressed by other Loom features (https://openjdk.org/jeps/453 https://openjdk.org/jeps/453), and others will be addressed by future ones (like channels).

avodonosov 3y ago
BlockingQueue is a kind of channel already, what are you thinking to add? And to the main point, of course, Java has plenty of thread comrunioation possibilities, Loom just makes threads cheaper.
- pron 3y ago
  > BlockingQueue is a kind of channel already, what are you thinking to add? The main difference between a channel and a BlockingQueue is that a channel can be closed, i.e. it allows one or both sides to signal the other that they're done producing/consuming. > And to the main point, of course, Java has plenty of thread comrunioation possibilities, Loom just makes threads cheaper. Definitely.

ye-olde-sysrq 3y ago

99% of which problem, though? IMO the whole point of Loom, and what I'm looking forward to, is code that looks like this: fooer.onCompletion(() -> System.out.println("yay")); fooer.onError(e -> System.out.println("o no")); fooer.foo(); // foo is some long operation can once again simply be: try { foo() S.o.p("yay"); } catch(Exception e) { S.o.p("o no"); } just like any college kid would've written 20 years ago in their CS 101 class in the chapter on exceptions. Many multi-threaded programs today don't even have a "communication among threads" problem. - they avoid it by simply not communicating between threads. They precompute work splits and then farm it out, and then gather up all the results. Consider HTTP servers or RPC handlers. A request is farmed out to them, they do a bunch of IO stuff to answer it, and then release their thread back to a pool. That's a huge use-case that gets materially improved right there. Look at what goroutines did for go programming.