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!
Right, 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.
A 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.
IMO, 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.
Agreed. 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.
