I just watched Roman Elizarov's presentation on <coroutines and project loom>. There, he seemed to a...

# coroutines

[Jarkko Miettinen]

I just watched Roman Elizarov's presentation on

coroutines and project loom▾

. There, he seemed to allude that function coloring is a good thing and not just for the reason that we can optimize stack copying for the few functions that can do it (suspend).

Some

other commenter▾

stated that that's because it provides structured concurrency.

What am I missing when I am thinking that you could build a structured concurrency similar to Kotlin coroutines on virtual threads, without any need for function colors?

[stojan]

Java is also building that

https://openjdk.org/jeps/428

[Jarkko Miettinen]

Yeah I know about the JEP. But is there something in the current kotlin structured concurrency that could not be build without compiler support and with virtual threads?

[yschimke]

I think the suspend keyword helps a lot here. Also requirements like suspend functions being main thread safe. On JVM the built in sockets will be loom safe, but how do you actually know about some Conscrypt SSL Socket, maybe it's not. Are you actually tying up one of your important threads?

[simon.vergauwen]

It’s not really the same as what we have in Kotlin, interruption vs cancellation are quite different mechanism.

Back-pressure on interruption is problematic afaik.

inline also solve a big portion of the issue of coloured functions. I.e you can call suspend from inside Iterable#map

+1 to what @yschimke said.

[Jarkko Miettinen]

Okay I didn’t understand the conscrypt part. Is it about some lib having their own low-level constructs that they’re using that can block whatever thread without yield?
Seems like what would happen with coroutines, no?

[yschimke]

Every library you use and the JDK needs to be rewritten to be loom safe. If you just use built in sockets it all just works. But if your code uses say JDBC, you will rely on that provider at runtime being loom safe.

[yschimke]

With coroutines, you would put any blocking IO on the IO scheduler. But with loom you won't know unless the library tells you

[yschimke]

I guess it's blocking JNI calls, raw long synchronization blocks. I'm not an expert.

[Jarkko Miettinen]

On the io scheduler, can you not use a specific pool of carrier threads for the same effect? There’s no way around the fact that low level constructs must support this which I can see happening when there’s platform support

[Jarkko Miettinen]

It seems that there’s only one global thread pool so you potentially starve it and all virtual threads instead of just one of potentially many pools (io and other schedulers)

[yschimke]

I wonder if you know when to use those threads.

[Jarkko Miettinen]

Me specifically or passive you? 😄

[yschimke]

Passive me. Seems like it automatically works well, if you implicitly know every library you use is designed for loom.

[yschimke]

Also Rx, Guava, Coroutines all seem to map cleanly between each other. Loom challenges that. Chooses an approach, without an API to convert, instead assuming things about implementations that you can't know from signatures.