2 ms·
I don't think there's any day to day problem that needs more threads than you can get ahold of. This is especially true when you consider you can tune the JVM
by jayd16 5y ago
I don't think there's any day to day problem that needs more threads than you can get ahold of. This is especially true when you consider you can tune the JVM accordingly for the special cases.
That said, Loom is a neat tool and I expect new, more convenient patterns will pop up from Loom.
I'll be interested to see how Java tackles OS thread problems after Loom. We'll still live in a world where most(all?) GUIs frameworks revolve around single thread concurrency and GPU access is still single threaded. I don't see how the implicit threading of loom is going to work for that, and it also seems like a line in the sand has been drawn in the face of async/await. We'll just have to see what comes of it.
- kaba0 5y agoThe JVM will still create an OS thread by the default way. You have to explicitly create virtual threads to use loom.
- pjmlp 5y agoUnless they changed the behaviour, that wasn't the case last time I checked a talk on it. Rather virtual threads get created by default and an explicit call, or thread factory can be used to get the value back. At least that is how I remember it.
- jayd16 5y agoYeah, so if you have to explicitly call the new API when you need to use it form an OS thread, its not very implicit. That's what makes me curious about how they'll smooth that out.
- kaba0 5y agoIf you already have an executorservice, calling createVirtualThread is all you need to use Loom afaik.