Vsevolod Tolstopyatov

That's a new pattern of usages for us, thanks! Maybe you could share a reproducer with a iOS code that triggered this issue?

Good point, `yield` indeed may increase CPU consumption in an unpredictable manner. >This will generally not be possible to do; supporting a non-spin waiting system requires use of a compare-and-set...

What is possible to do is to release a separate variant of the `kotlinx-coroutines-core` where transformations are not applied (it's a bit trickier probably because non-transformed code depends on `atomicfu`...

Thanks for the detailed explanation! I have a few questions about your expectations from such an API: 1) Suspendability support Do you expect the code from `invokeOnCompletion` be cancellable on...

>If we forget about backward compatibility, I'm certain this is the way to do it I tend to agree with this statement. Great job with figuring it out! I would...

>(It also feels like the inconsistency exists only for the sake of API beautification, I hope I'm wrong here, correct me, please) One more reason to move towards public design...

>I'm afraid that this inconsistency will quickly become a gotcha. Could you please provide a few examples where this behaviour is a problem or a gotcha that required a fix?

On a side note, there seems to be a misconception about `limitedParallelism(1)` being "racy", for example -- https://github.com/KStateMachine/kstatemachine/blob/master/docs/index.md#use-single-threaded-coroutinescope While this might not be a goal of our documentation per se,...

>-javaagent is not a production-level solution for IJ From our internal notes: * Passing `-javaagent` everywhere in each launch script is quite a lot of technical burden * It potentially...

https://youtrack.jetbrains.com/issue/KT-62096/Consider-replacing-JVM-agent-specific-kotlin.coroutines.jvm.internal.DebugProbesKt-with-SPI-based-mechanism