What’s the best way to cleanup things that you create in a coroutine? I’m especially worried about r...

# coroutines

[ansman]

What’s the best way to cleanup things that you create in a coroutine? I’m especially worried about removing created resources when being cancelled.

myScope.launch {
    // If the job is canceled before createResourceSync() returns the resource is lost in transit
    val resource = withContext(Dispatchers.default) { createResourceSync() }
    try {
    } finally {
      resource.delete()
    }
}

[Dominaezzz]

May not be the best but...

myScope.launch {
    // If the job is canceled before createResourceSync() returns the resource is lost in transit
    val resource: ResourceType
    try {
        resource = withContext(Dispatchers.Default) { createResourceSync() }
    } finally {
      resource.delete()
    }
}

[Dominaezzz]

I'm not sure if resource has to be a nullable var and resource?.delete(). Can't check right now.

[ansman]

That would lead to the same issue

[Dominaezzz]

How so? delete will be called.

[ansman]

If the job is cancelled the resource is lost

[ansman]

Because the coroutine wouldn’t be resumed

[Dominaezzz]

Hmm but it would be cancelled.

[ansman]

Yes, but if but a cancelled coroutine doesn’t resume

[Dominaezzz]

To my knowledge, cancel means resume with CancellationException or something.

[ansman]

It does, but instantly. It doesn’t wait for the child to complete

[Dominaezzz]

Oh, are you worried about what happens within createResourceSync?

[ansman]

Nope, since it’s sync it will always complete

[ansman]

Here is your example as a scratch file:

runBlocking {
    val job = launch {
        var resource: String? = null
        try {
            resource = withContext(Dispatchers.Default) {
                Thread.sleep(100)
                "Hello"
            }
        } finally {
            println("Resource is $resource")
        }
    }
    delay(10)
    job.cancel()
}

[Dominaezzz]

How about,

myScope.launch {
    // If the job is canceled before createResourceSync() returns the resource is lost in transit
    val resource: ResourceType
    try {
        withContext(Dispatchers.Default) {
            resource = createResourceSync()
        }
    } finally {
      resource.delete()
    }
}

[ansman]

It will print "Resource is null"

[ansman]

Same thing, the exception is thrown instantly and the resource would not have been set yet

[ansman]

As I mentioned in the original issue the problem is solvable using atomic references but it’s complicated and error prone

[Dominaezzz]

It will be thrown by withContext but not within it. resource would have been set.

[ansman]

It won’t if createResourceSync hasn’t returned yet

[ansman]

This is the only way to solve the issue AFAIK:

val ref: AtomicReference<Resource?> = AtomicReference()
withContext(Dispatchers.Default) {
    ref.set(createResourceSync())
    if (!isActive) {
        ref.getAndSet(null)?.delete()
    }
}

val resource = ref.getAndSet(null)
try {
    // Do stuff with resource
} finally {
    resource?.delete()
}

[Dominaezzz]

I don't think you need atomics for that, since your code is synchronous.

[ansman]

My code is not sync since I use the default dispatcher

[Dominaezzz]

withContext is synchronous.

[Dominaezzz]

It may run on a different thread but it's still synchronous.

[ansman]

Well, it depends on what your definition of synchronous is. Regardless you need the atomic ref unless you’re ok with deleting the resource twice

[Dominaezzz]

By synchronous, I mean sequential. No concurrency.

[ansman]

That is correct, sort of. If cancelled while createResourceSync is running the exception will be thrown (and enter the finally block) while still running createResourceSync so in a sense it is concurrent in some circumstances

[Dominaezzz]

Hmm, I see what you're saying but I doubt they'd let concurrency be introduced. As it complicates things like it is right now.

[ansman]

Well, regardless that is how it works 🙂

[Dominaezzz]

I don't know enough to argue this but I found something you might like.

[Dominaezzz]

https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-non-cancellable.html

[Dominaezzz]

Add that to withContext 🙂

[Dominaezzz]

myScope.launch {
// If the job is canceled before createResourceSync() returns the resource is lost in transit
val resource: ResourceType
try {
withContext(Dispatchers.Default + NonCancellable) {
resource = createResourceSync()
}
} finally {
resource.delete()
}
}

[ansman]

NonCancellable won’t solve the issue since the parent cannot be resumed after cancelling. It just means don’t interrupt whatever is running, it will still throw an exception instantly

[Dominaezzz]

But finally would run and resource will be set.

[ansman]

Finally would run but resource would not have been set yet

[ansman]

Actually, I believe it will be resumed when using NonCancellable but it will still cause issues if the code within withContext uses any coroutines

[ansman]

One problem with NonCancellable is that withContext won’t throw so you’d have to check isActive manually