I am running into a problem where I don't really u...

# coroutines

[dirk.dittert]

I am running into a problem where I don't really understand what is going on. I traced it down to this part of the code:

val device = withTimeout(Duration.parse("1s")) {
    println("before filestore").       // is printed
    val tmp = path.fileStore().name() // seems to freeze here
    println("Filestore name: $tmp")   // not printed
    tmp
}

The execution stops after before filestore is printed. Unfortunately, it runs on a machine where I can't just attach a remote debugger. How can the execution freeze at that point? I would expect to run into a TimeoutCancellationException after one second. However, that does not happen.

[ross_a]

You might be running into the issue where TimeoutCancellationException extends CancellationException which means that coroutines treat it specially

[ross_a]

https://github.com/Kotlin/kotlinx.coroutines/issues/1374

[dirk.dittert]

Good point. Let me surround that with a try-catch and see if the exception occurs

[dirk.dittert]

I replaced it with that:

val device: String = try {
    withTimeout(Duration.parse("1s")) {
        println("before filestore")
        val tmp = path.fileStore().name()
        println("Filestore name: $tmp")
        tmp
    }
} catch (e: TimeoutCancellationException) {
    e.printStackTrace()
    "invalid"
}

Execution does not seem to run into the catch-clause.

[Robert Williams]

Cancellation is cooperative - assuming filestore() and/or name() are blocking (not suspending) functions they won't react to the coroutine being cancelled because they're not aware of/ expecting it. Because of structured concurrency the coroutine can't complete until they return.

[ross_a]

ok, just looked at Path.fileStore, it's not a coroutine so it doesn't suspend so the Duration wouldn't affect it anyway?

[ross_a]

I don't know if it is Interruptible, if it is then you can wrap path.fileStore() in runInterruptable

[dirk.dittert]

it seems like it is not interruptible and just blocks

[dirk.dittert]

Ok, my solution is to work around the problem. It seems like Path.filestore() seems to block indefinitely on a broken symbolic link (for whatever reason). I am checking for that corner case and avoid it.

I learned from this that there is no point in wrapping filesystem IO operations with coroutines as they would just block anyway and there is no way to cover for this in the cooperative approach of coroutines.

[ephemient]

you might want to use runInterruptible - it translates coroutine cancellation into Java thread interruption, which interrupts most Java I/O

[Edoardo Luppi]

Did not know about runInterruptible, nice one!