I'm attempting to convert a blocking function from an API to a suspending call. After doing a lot of...

# coroutines

[Mark Vogel]

I'm attempting to convert a blocking function from an API to a suspending call. After doing a lot of research, what I've found is that I should use withContext(<http://Dispacters.IO|Dispacters.IO>) (for I/O functions).
For example, more specifically, I'm attempting to convert the fetch() from jOOQ to a suspending function:

suspend fun <R : Record> ResultQuery<R>.await(): Result<R> =
    withContext(<http://Dispatchers.IO|Dispatchers.IO>) { fetch() }

Is this the correct way of going about this?

[ephemient]

https://www.jooq.org/doc/latest/manual/sql-execution/fetching/reactive-fetching/ could be better; asFlow will convert a ResultQuery<R> into a Flow<R>

[Mark Vogel]

Is that simply doing the same kind of thing, though, as withContext(Dispatcher) under the hood?

[ephemient]

no, you'd still want a .flowOn(<http://Dispatchers.IO|Dispatchers.IO>) that way

[ephemient]

but it would allow for not tying up a thread performing a blocking fetch, if the underlying publisher is truly async

[Mark Vogel]

I see. I guess I'm still not versed enough in the underlying nature of coroutines. Are you able to explain how Kotlin waits for the result on something like this without blocking a thread? Is it a native function of the language?

To my knowledge, even an async program still has to block dedicated I/O threads to wait for something like a database

[ephemient]

with R2DBC a dedicated thread isn't required

[ephemient]

with .asFlow(), Kotlin suspends (allowing the underlying thread to handle other coroutines) until upstream publishes another record

[ephemient]

jOOQ documentation looks like it'll still block if you're using that API with a backend that doesn't support async. not clear to me if it blocks the current thread or one from its own threadpool, though

[Mark Vogel]

Yeah that's what I'm seeing as well. Seems as though I need to include that driver; I'll have to read more on that. I appreciate the information

[Mark Vogel]

Furthermore, if the underlying API doesn't support the reactive Publisher (e.g. outside of jOOQ etc.), what is the best way to convert a blocking function to suspending? To somehow wrap it as a Flow?

[ephemient]

depends. if it's a single operation then it should just be a suspend fun. if it returns multiple results then a Flow<*> is better (and functions returning Flow should generally not be suspend themselves)

[ephemient]

but ideally whatever you're wrapping has an async API. if it's callback-based, then you can use suspendCancellableCoroutine or callbackFlow to adapt it. if it's using Java8 futures, Java9 publishers, Reactive Streams, RxJava, etc… then there's already adapters that exist

[Mark Vogel]

Okay that makes sense. I'm guessing then the final fallback would be withContext to block a thread and suspend until the blocking function returns?

[ephemient]

well, the coroutine doesn't suspend in that case, but yes

[Mark Vogel]

To clarify, wouldn't it suspend the coroutine being run by thread A and instead block thread B while thread A still does work? It doesn't make sense that it wouldn't suspend the coroutine (it says it does in IntelliJ)

[ephemient]

withContext does suspend on the original dispatcher, but then the coroutine on the IO dispatcher is blocking, not suspending

[Mark Vogel]

Okay yes that makes sense

[Mark Vogel]

Thanks for all the info

[gildor]

also if blocking operatioon supports interruption, you may concider to wrap it with https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/run-interruptible.html

[ephemient]

good point, I forgot to mention