Comment by pron | Hacker News Reader

Comment by pron | Hacker News Reader

> 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 parallel streams.

> It doesn’t help you with user interfaces that use a single event thread.

It might. Loom allows you to plug in your own scheduler, and it is a one-liner to schedule virtual threads on the UI thread:

    var uiVirtualThreadFactory = Thread.builder().virtual(java.awt.EventQueue::invokeLater).factory();

All threads created by this factory will be virtual threads that are always "carried" by the UI OS thread. This won't currently work because each of those threads will have its own identity, and various tests in the UI code check that the current thread is actually the UI thread and not any thread that is mapped to the same OS thread. Changing these tests is something the UI team is looking into.

>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 background but you need a block of OpenGL tasks to retain control.

I just don't see how you can do this implicitly in a way that's cleaner than async/await. It seems like posting tasks to this thread factory or that will get the job done but is that an improvement?

It sounds like for now this stuff will still be using the current model of posting unyielding runnables to a thread. That's fine I guess. Loom still seems very cool, it just doesn't cover the cases I deal with a lot more often.

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.

> 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.

Reply on news.ycombinator.com