https://kotlinlang.org logo
Join Slack
Powered by
I think Kotlin's coroutines are "stackless", and l...
# coroutines
t
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?
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.
j
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
e
fibers are just a normal Thread to most code, and that's the level of interoperability that I'd expect from loom & kotlin coroutines
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
now, if kotlin wanted to use loom continuations… that seems more challenging
t
Why would it be hard to use loom? because of the stackless / stackfull thing?
e
it will not be hard to use loom in the way that existing java interop works
t
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.
e
Loom coroutines aren't a compiler trick, they're built into the runtime, and the implementation is effectively invisible to the code running
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.
none of that will work with "native" loom coroutines
t
so.. are loom fibers premtable at non suspend points?
e
as much as the thread that they're bound to is preemptable
t
so they are the same then, in that they run to the next suspend point w/o interruption (except by the OS)
I assume you can write you own code that suspends a loom fber, just like a kotlin coroutine.
e
I don't see anything in https://download.java.net/java/early_access/loom/docs/api/preview-list.html that indicates that you can
LockSupport.park() should, just like in a classic Thread, but you can't do anything new with it
t
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.
e
if you suspend on standard locking methods, those park the thread/fiber in a similar way too
but it seems there is no way to do anything else from user code
8 Views
Open in Slack
PreviousNext
Powered by