3 ms·
Loom's virtual threads allow you to do the same with a pluggable scheduler.
by pron 6y ago
Loom's virtual threads allow you to do the same with a pluggable scheduler.
- jayd16 6y agoHow 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?
- pjmlp 6y agoYou can still pick and choose, native threads aren't going away, just like today you can make several tasks map to a single threaded.
- jayd16 6y agoAlright. 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"?
- pjmlp 6y agoCode 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.
- pron 6y agoYou would use a custom scheduler to schedule many virtual threads onto a particular native thread.
- jayd16 6y agoI don't think this is enough. You still might interweave your draw commands, causing issues.
- pron 6y agoYou can get the exact same result as with async/await.
- jayd16 6y agoIf 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?