4 ms·
This blogpost does rely on plugging in an executor. While the API was removed, it’s one private variable away (documented in footnote). As you say, it seems lik
by CHY872 4y ago
This blogpost does rely on plugging in an executor. While the API was removed, it’s one private variable away (documented in footnote). As you say, it seems like it’s an ‘on the way, but later’ thing - the last Loom preview I used (a while ago) actually had the API so when I started drafting this post I was unhappily surprised!
- cogman10 4y agoIMO, they are focusing on the right thing here. Getting a good virtual thread API GA will be paramount in the decisions around scheduling and continuations in the future. Maybe a little disappointing for low level nuts and other languages like kotlin, but the right move IMO. Virtual threads alone will be a huge benefit to the ecosystem. The other stuff will help, but won't have near the same impact.
- CHY872 4y agoAgreed. And the pluggable scheduling is still a key part of it, just doesn’t need to be a thing to get right out of the gate. I’m honestly mega excited that Loom is even a real thing that exists and that you can use.
- pron 4y agoRight, custom schedulers aren't quite ready for release yet -- there's a small missing piece in the VM that's required to fully preserve the spec, and they need a lot of testing that we don't yet have -- so we decided to go ahead without them and add them later.
- CHY872 4y agoWhat’s the missing piece?
- pron 4y agoA technical detail. Monitors (synchronized) record their owners as the OS thread, which makes the VM not know whether the carrier or the virtual thread owns a monitor, as they both share the same OS thread.
- CHY872 4y agoFor any future readers, I think this is the bug: https://bugs.openjdk.java.net/browse/JDK-8281642 https://bugs.openjdk.java.net/browse/JDK-8281642