I think Kotlin s coroutines are stackless and loom s are rep

Question

I think Kotlin s coroutines are stackless and loom s are reported to be stackfull Any thinking from JB on what to expect when loom ships

TwoClocks · Answer

It s very likely netty jetty etc are going to make loom aware versions or maybe a new one from scratch If there is no integration then ktor projects will not be able to interact with any loom based code and visa versa That would super suck You d have to pick 100 kotlin or 100 loom based code

Joffrey · Answer

From what I ve read here and there coroutines will be able to leverage loom fibers when they re out You won t have to choose one or the other

ephemient · Answer

fibers are just a normal Thread to most code and that s the level of interoperability that I d expect from loom amp kotlin coroutines

ephemient · Answer

there s probably some benefits to a coroutine scheduler that is loom aware but I would guess that there are won t be any changes needed to how coroutines codegen works or to any other part of the kotlinx coroutines library

ephemient · Answer

now if kotlin wanted to use loom continuations that seems more challenging

TwoClocks · Answer

Why would it be hard to use loom because of the stackless stackfull thing

ephemient · Answer

it will not be hard to use loom in the way that existing java interop works

TwoClocks · Answer

right But I assume loom s coroutines are similar to kotlins in that it s a basically a compiler trick to hid callbaks and a bunch of syntactic sugar and libs on top of that

ephemient · Answer

Loom coroutines aren t a compiler trick they re built into the runtime and the implementation is effectively invisible to the code running

ephemient · Answer

Kotlin coroutines compiler code is built around creating a reified continuation in actual bytecode and kotlinx coroutines hooks into build scopes for structured concurrency etc

ephemient · Answer

none of that will work with native loom coroutines

TwoClocks · Answer

so are loom fibers premtable at non suspend points

ephemient · Answer

as much as the thread that they re bound to is preemptable

TwoClocks · Answer

so they are the same then in that they run to the next suspend point w o interruption except by the OS

TwoClocks · Answer

I assume you can write you own code that suspends a loom fber just like a kotlin coroutine

ephemient · Answer

I don t see anything in <https download java net java early access loom docs api preview list html> that indicates that you can

ephemient · Answer

LockSupport park should just like in a classic Thread but you can t do anything new with it

TwoClocks · Answer

hmm I assume they suspend for IO operations but only the ones they are aware of So if you want to do IO any other way you can t use loom efficiently that seems exception short sited It can t be true I ll have to go and dig around

ephemient · Answer

if you suspend on standard locking methods those park the thread fiber in a similar way too

ephemient · Answer

but it seems there is no way to do anything else from user code