To keep things simple until we have a need for something more complex, we run controller code as blo...

# coroutines

[Jonathan Mew]

To keep things simple until we have a need for something more complex, we run controller code as blocking (using ktor).
With that in mind, if I'm calling into a suspend function in a 3rd party library that makes network calls, is this a reasonable construct to use?

runBlocking(<http://Dispatchers.IO|Dispatchers.IO>) {
    try {
        thirdParty.doNetworkStuff()
    } catch (e: Exception) {
        log.warn("recoverable error", e)
    }
}

[Jonathan Mew]

just want to make sure I'm not falling into any obvious gotchas

[gildor]

Dispatchers.IO is most probably redundant for your case

[gildor]

But in general i’m not sure that it’s good approach (except some dirty hack for migration period) to use runBlocking

[Jonathan Mew]

Would you mind expanding on redundant? Is it because it's likely the library does that for me under the hood?

[gildor]

because you alredy blocked your current thread by wrapping with runBlocking, why do you want to execute this operation on one more thread on IO (so use 2 threads instead of 1)

[gildor]

also wrapping to IO dispatcher is not needed for non-blocking suspend functions, it should be used to wrap some blocking (IO bound) code

[Jonathan Mew]

I guess I should just bite the bullet and push for the calling function to be suspend. Because we haven't invested in coroutine knowledge, I think the sight of a suspend function feels like complexity, and we have generally avoided it.

[Jonathan Mew]

thanks @gildor

[gildor]

Why do you use coroutines based network library in this case?

[gildor]

Also you limit your scalability when convert non-blocking code to blocking

[Jonathan Mew]

we already use ktor, so when considering which http client to use, it seemed most straightforward to pull in the ktor implementation

[gildor]

Ktor is completely coroutines based, so not sure how can you avoid using suspend functions there and why

[Jonathan Mew]

and yes it will limit scalability to some degree, but we may well not need to scale so much that it becomes an issue, and might have other bottlenecks we hit first. If it becomes the issue that needs fixing, we'll invest in that coroutine knowledge.

[gildor]

If you already use Ktor, you have 2 choices: drop ktor or learn how to use coroutines

[gildor]

I think it’s not the best strategy

[gildor]

especially keeping in mind that use suspend functions is very easy

[Jonathan Mew]

The ktor CRUD methods are not suspend though

[gildor]

You essentially creating unncessary technical depth from the beginning

[gildor]

The ktor CRUD methods are not suspend though

What do you mean?

[gildor]

isn’t every Ktor callback is suspend lambda?

[Jonathan Mew]

fun <T:Table> T.insert(body: T.(InsertStatement<Number>)->Unit): InsertStatement<Number>

[Jonathan Mew]

for example in Queries.kt

[Jonathan Mew]

or maybe I'm missing the point

[gildor]

Could you share a link on this function

[gildor]

looks as somethind DB specific, not Ktor

[gildor]

Maybe it’s part of Expose, not Ktor

[gildor]

also yeah, it looks as blocking function

[Jonathan Mew]

Sorry, terrible sleep this week, that's exposed.
You're right, ktor drops us into a suspend function, we just switch straight over to dispatchers IO and treat it as blocking code.

[gildor]

yes, sounds as good way to work with blocking block from asyncronous context

[Jonathan Mew]

(again, because it's simpler for the team to work with and it's not causing us issues - we know we're not making the most of it)

[gildor]

just wrap it to IO

[gildor]

I understand how wrapping to IO dispatcher make sense, but than I’m not sure why do you need runBlocking

[Jonathan Mew]

Generally we have a layered architecture. The (suspend) handler delegates to some service(s) and they generally don't have suspend functions. I think in this case though I'm going to push for an exception.

[Jonathan Mew]

The runBlocking was to follow that pattern and keep to non-suspend service functions. I think it's a strong enough argument against in this case though.

[Jonathan Mew]

The worry is that we'll botch something unexpected like exception handling while we haven't invested in better understanding of coroutines.
Thanks for your help and advice!

[Evan R.]

@Jonathan Mew exposed calls are not thread safe by default, make sure to use the built-in coroutine support when starting your transactions: https://github.com/JetBrains/Exposed/wiki/Transactions#working-with-coroutines

Note however that it’s experimental

[Jonathan Mew]

@Evan R. thanks for that - is it fairly new? I don't remember seeing it when we were starting out. I resorted to handling the threadlocal transaction manager survival myself for use during testing, but haven't hit issues apart from that. I'll have a read.

[Evan R.]

Yeah I think it’s kind of new but it is experimental. I personally ran into a minor issue where attempting to nest newSuspendedTransaction calls will throw an exception, but a fix was made for it. Not sure if it’s merged yet though.

[Evan R.]

Did a little digging. The fix was just merged to master yesterday, I assume it will be available in exposed 1.17.7.

[Jonathan Mew]

Haha... I might hold off rushing into it given we don't have issues currently. Maybe one for when we next upgrade exposed.