Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Loom and Structured Concurrency

javaadvent.com

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Project Loom and Structured Concurrency

#91

Post by latchkey »

Cojen wrote: post #87
latchkey wrote: post #83

Programming challenge in golang: Create a persistent tcp client that can connect to a server, read responses… and be disconnected via context.WithCancel().

I'm not familiar enough with Go to understand why this is a challenge. What point are you trying to illustrate with the challenge? Is this easy or hard, and how does this compare to Loom and Structured Concurrency?

Many people in this thread are talking about structured concurrency in other languages. I brought up a fun one for golang that, as far as I can tell, is a 3 year old open issue [0] that I've recently bumped into.

Maybe this is a fun challenge for you to become more familiar with golang?

[0] https://github.com/golang/go/issues/20280

Re: Project Loom and Structured Concurrency

#92

Post by pron »

jayd16 wrote: post #81
pron wrote: post #7

> It does nothing for you if you have computationally intensive tasks and want to keep all processor cores busy. I would argue this isn't concurrency at all (the job of juggling mostly independent tasks, and scheduling them to a relatively small number of processing units), but parallelism (the job of performing a single computational task faster by employing multiple processing units), and exactly the job of paralle…

>All threads created by this factory will be virtual threads that are always "carried" by the UI OS thread Does this actually solve the problem? I don't see it. We want to interweave foreground and background work. Sometimes that means blocking work will yield, sometimes that means it should not yield because conceptually several tasks should retain exclusive control of that thread. You might want some IO task on the…

It does (or will do, once the checks in the UI code are fixed) exactly what you want it to do. All computation will be done on the UI OS thread. All blocking operations will release it to do other things so it remains responsive. If you want to compute something outside it -- just spawn another thread that's not mapped to it.

Re: Project Loom and Structured Concurrency

#93

Post by kasperni »

pron wrote: post #72
jnwatson wrote: post #26

Earlier quoted context omitted.

It is an unfortunate abuse of an existing facility for something quite different.

The API is not yet final, but I wonder why you think it's "an abuse of an existing facility for something quite different," and whether this could just be a matter of a habit rather than purpose. Take a look at the description of ExecutorService ( https://docs.oracle.com/en/java/javase/15/docs/api/java.base... ) and Executors ( https://docs.oracle.com/en/java/javase/15/docs/api/java.base... ). I think we're using the…

I think the common mental model of an ExecutorService for most people is something static and heavyweight and whose main task is to avoid expensive thread creation. When used with SC they are suddenly created and thrown away without a blink. And are mostly tasked with coordination. So people will probably need some time to adjust.

Re: Project Loom and Structured Concurrency

#94

Post by pron »

kasperni wrote: post #93
pron wrote: post #72

Earlier quoted context omitted.

The API is not yet final, but I wonder why you think it's "an abuse of an existing facility for something quite different," and whether this could just be a matter of a habit rather than purpose. Take a look at the description of ExecutorService ( https://docs.oracle.com/en/java/javase/15/docs/api/java.base... ) and Executors ( https://docs.oracle.com/en/java/javase/15/docs/api/java.base... ). I think we're using the…

I think the common mental model of an ExecutorService for most people is something static and heavyweight and whose main task is to avoid expensive thread creation. When used with SC they are suddenly created and thrown away without a blink. And are mostly tasked with coordination. So people will probably need some time to adjust.

Some adjustment to the fact that threads are not necessarily costly resources will be required, but would putting the newThreadExecutor (and the specialised newVirtualThreadExecutor) method in a class other than Executors, where it is one among many other methods, and perhaps have it return a subclass/interface of ExecutorService make the adjustment easier? This is something we're seriously considering (especially as that particular ExecutorService might have other implications, such as how thread dumps are produced).

Re: Project Loom and Structured Concurrency

#95

Post by jayd16 »

pron wrote: post #92
jayd16 wrote: post #81

Earlier quoted context omitted.

>All threads created by this factory will be virtual threads that are always "carried" by the UI OS thread Does this actually solve the problem? I don't see it. We want to interweave foreground and background work. Sometimes that means blocking work will yield, sometimes that means it should not yield because conceptually several tasks should retain exclusive control of that thread. You might want some IO task on the…

It does (or will do, once the checks in the UI code are fixed) exactly what you want it to do. All computation will be done on the UI OS thread. All blocking operations will release it to do other things so it remains responsive. If you want to compute something outside it -- just spawn another thread that's not mapped to it.

I feel like I must not be communicating the issue properly.

Sometimes, like with with several GL calls or layout operations, you want the UI to be blocked because that is the synchronization model openGL requires. Single thread ordering is not enough. We need specific exclusive scheduling of critical sections and I don't see how this system can understand that without just as much or more work as async/await styles.

Perhaps we will get some new way to render UI out of this. I'm excited to see what the UI team comes up with once it all works. However, my pessimistic assumption is that we will simply stick with native non-premptive threading.

Re: Project Loom and Structured Concurrency

#96

Post by yxhuvud »

valenterry wrote: post #18
jillesvangurp wrote: post #11

Since the article goes out of its way to not mention Kotlin, I'll do it for them since this is both lame and more than a bit disingenuous. Arguably, Kotlin co-routines (and the Flow API) provides a very nice implementation of the exact same concepts on the JVM. As far as I know, the loom integration is already planned and probably implemented to a large degree. Mostly doing that should be straightforward as this pret…

What makes you think that Kotlin should be mentioned? Especially since concurrency in Kotlin is really not great, compared to concurrency in Erlang or Scala.

For starters, because the concurrency story in Kotlin is also built on the structured concurrency idea.

Re: Project Loom and Structured Concurrency

#97

Post by kasperni »

pron wrote: post #94
kasperni wrote: post #93

Earlier quoted context omitted.

I think the common mental model of an ExecutorService for most people is something static and heavyweight and whose main task is to avoid expensive thread creation. When used with SC they are suddenly created and thrown away without a blink. And are mostly tasked with coordination. So people will probably need some time to adjust.

Some adjustment to the fact that threads are not necessarily costly resources will be required, but would putting the newThreadExecutor (and the specialised newVirtualThreadExecutor) method in a class other than Executors, where it is one among many other methods, and perhaps have it return a subclass/interface of ExecutorService make the adjustment easier? This is something we're seriously considering (especially as…

I appreciate the cleverness of just adding AutoClosable to ExecutorService. But I definitely think returning a specific subclass/interface of ExecutorService would be a great help. I think at the expense of an extra class, something like this is a lot easier for people to wrap their head around:

  try (Nursery n = Nursery.spawn()) {
    n.submit(() -> foo());
    n.submit(() -> bar());
  }

  try (Nursery n = Nursery.spawnWithDeadline(Instant)) {
    ...
    try (Nursery nx = n.spawn()) {
      nx.submit(() -> foo());
      nx.submit(() -> bar());
    }
    ...
  }
...

Re: Project Loom and Structured Concurrency

#98

Post by jdlshore »

breatheoften wrote: post #90
jnwatson wrote: post #29

I have a lot of experience using concurrency in Go, and for the last couple years have been at the bleeding edge of Python async. The tradeoffs between the two approaches are immense. With the virtual thread model you have: * No function coloring problem. This also means existing code is easier to port. * possibility of transparent M:N scheduling. * Impedence mismatch with OS primitives. * Much more sophisticated run…

I'm not sure I really think of function coloring as a "problem" ... facebook is experimenting with auto differentiation for Kotlin and looks like it's adding a new "differentiable" function color -- https://ai.facebook.com/blog/paving-the-way-for-software-20-... It looks very easy to reason about and use to me ... and i personally find async a similarly useful marker ... It's about being able to push constraints from…

There was a series of essays about esoteric language features posted here a few weeks ago, and one of them was exactly what you're talking about. It was a functional language, with the ability to mark functions as involving I/O, non-terminating, or (I think) arbitrary custom "colors."

It was an academic language, but very interesting. Sadly, I don't remember the name. Maybe somebody else can post the link.

Re: Project Loom and Structured Concurrency

#99

Post by pron »

jayd16 wrote: post #95
pron wrote: post #92

Earlier quoted context omitted.

It does (or will do, once the checks in the UI code are fixed) exactly what you want it to do. All computation will be done on the UI OS thread. All blocking operations will release it to do other things so it remains responsive. If you want to compute something outside it -- just spawn another thread that's not mapped to it.

I feel like I must not be communicating the issue properly. Sometimes, like with with several GL calls or layout operations, you want the UI to be blocked because that is the synchronization model openGL requires. Single thread ordering is not enough. We need specific exclusive scheduling of critical sections and I don't see how this system can understand that without just as much or more work as async/await styles.…

> I don't see how this system can understand that without just as much or more work as async/await styles

I didn't say it was less work; probably just as much. The benefits over async/await are elsewhere: in the tooling support and in the lack of split APIs/programming models.

Re: Project Loom and Structured Concurrency

#100

Post by vips7L »

ragnese wrote: post #42
jillesvangurp wrote: post #36

Earlier quoted context omitted.

The difference is that Kotlin has been gobbling up Java users using Java frameworks like Android and Spring. Coroutines are used in both and implement structured concurrency exactly like Loom does. It's not a little bit similarish and vaguely related: it maps 1 to 1 conceptually; well at least for the stuff that Loom actually implements. Rust indeed would deserve a mention as well but it follows a somewhat different…

I think that Kotlin's existence has really given Java a kick in the pants. I agree that there has been a lot of people picking up Kotlin because of how verbose and "last century" programming in Java feels. Modern (static typed, imperative, algol-like) languages are so much more ergonomic (Rust, Go, Kotlin, Swift, TypeScript, etc), that it's kind of painful to go back to Java, with its silly "everything has to be an o…

> ergonomic (Rust, Go, Kotlin, Swift, TypeScript, etc), that it's kind of painful to go back to Java.

I really don't know how you can include Go here. It's extremely unergonomic to manually write for loops, and to deal with pointers and references.

Post reply on HN