Hacker News Reader

Comment by ynik | Hacker News Reader

async/await is more flexible in some sense. If you run the tasks on a thread pool, it's mostly equivalent to green threads. But if you run the tasks on a single thread, you get cooperative multi-tasking. You can access mutable shared state without using locks, as long as you don't use "await" while the shared state is in an inconsistent state. For user interfaces this is huge advantage: you can run all your code on the UI thread; but the UI stays responsive while awaiting tasks.

Also, here's an interesting use of async/await: software hyperthreading: https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-...

View on HN

Loom's virtual threads allow you to do the same with a pluggable scheduler.

How does UI code work in Loom if you need, say, a single render thread to issue GL commands? Wouldn't you need a native thread (making Loom moot), or is there some other trick at play?

You can still pick and choose, native threads aren't going away, just like today you can make several tasks map to a single threaded.

Alright. The trick is to not use Loom virtual threads. I will say Java's Loom is ruthlessly elegant in this way.

But won't you run into issues where you don't want to call certain code from that UI thread? Isn't that "code coloring"?

Code colouring usually means it won't even compile, like on C# async/await case.

In your example, for Swing applications you should use invokeLater(Runnable r) anyway, and it doesn't matter what implements the interface.

You would use a custom scheduler to schedule many virtual threads onto a particular native thread.

I don't think this is enough. You still might interweave your draw commands, causing issues.

You can get the exact same result as with async/await.

If you have multiple virtual threads issuing non-atomic commands that must be run together and not interwoven, how does the scheduler know when it's ok to yield one thread to another without explicit support?

How can you set a shader and then draw a mesh each in two virtual threads without possibly interweaving their execution, for example?

>For user interfaces this is huge advantage: you can run all your code on the UI thread; but the UI stays responsive while awaiting tasks.

... assuming any other tasks/coroutines running on the UI thread are being cooperative and not doing bad things like waiting on synchronous functions or otherwise hogging the UI thread too much. Done right, it's a big performance and maintainability win over multithreading, but when done poorly, it can result in large variance in latency/responsiveness of any individual task.

Reply on news.ycombinator.com