A modern programming language that makes developers happier.

kotlinlang

I have a suspicion that the coroutines 1.3.3-native-mt artifacts may have been updated with some behavior changes recently

someone else reported changes in behavior, and I have spent all morning chasing a freezing exception from code that was working well previously

What code, and what exception? There is some interesting behavior, but if it’s related to things I’ve run into, it’s not “new”, just emerges with specific combinations of actions

its way too complicated to explain the whole flow, unfortunately, and I am having a real hard time distilling it down to the root cause

though I actually think i just found it...

somehow the way I am chaining exception handlers is causing issues with freezing way up the object graph

Still confused. Is there something being frozen that you don’t expect to be, is coroutines upset?

OK. The thing you don’t expect frozen. Why would you expect it to not be frozen, and how does it interact with coroutines?

so, setting a class member in an exception handler (an atomic reference to the exception) is what's causing the exception. the parent object is not allowed to be frozen.

obviously it's the capture that's the problem, not the set operation

Can you just pass the AtomicRef to the exception handler rather than the object it’s attached to?

Alternatively have the exception handler publish in a way you can listen to without getting attached

that's what is happening. they're both members of the same class. i've also tried freezing the atomic ref itself during intialization

I’ve split “scope” from the model classes (if that’s what you’re doing). Punted on the problem you’re talking about

```internal class MainScope(private val mainContext: CoroutineContext) : CoroutineScope {
    override val coroutineContext: CoroutineContext
        get() = mainContext + job + exceptionHandler

    internal val job = Job()
    private val exceptionHandler = CoroutineExceptionHandler { _, throwable -&gt;
        showError(throwable)
    }

    //TODO: Some way of exposing this to the caller without trapping a reference and freezing it.
    fun showError(t: Throwable) {
        printThrowable(t)
    }
}```

that's similar to what I am doing, except I need to save the reference to report it later on

There’s a good way to do it. Just haven’t put in the time

i made it a local var instead of a class member

what still doesn't make sense to me, is that this code was working previously

If the scope was doing anything in background threads, then I don’t see how. If the scope was attached to coroutines that crossed threads, it was frozen, and that’s been true for multiple preview versions

i am afraid it will remain a mystery because I don't have time to try to chase down what detail changed

If you were doing just ktor previously, that never left the thread, but other stuff would