general question: do I have to always write a cor...

# announcements

[Peter Ertl]

general question:

do I have to always write a coroutine variant of functions accepting lambdas? for example:

fun doit(callback: () -> Unit) = …
suspend fun doitAsync(suspend callback: () -> Unit) = …

or can I somehow declare a function that accepts both suspending and non-suspending? I can imagine that ‘suspend’ adds overhead in the non-suspending case due a compiler generated state machine for supporting async.

or: is it a reasonable approach to use runBlocking inside a non-suspending lambda or are there drawbacks?

[ephemient]

IMO runBlocking is definitely a bad idea for something which might be called from another coroutine, you lose track of the coroutine context

[Peter Ertl]

makes sense

[ephemient]

if you define inline fun doit(callback: () -> Unit) it should work in suspend

[Peter Ertl]

wow … inline does accept suspend_

[Peter Ertl]

?

[ephemient]

https://pl.kotl.in/QEr8IReo9

[ephemient]

it's not always a good idea to inline, but it is possible here

[ephemient]

otherwise yeah, the code generation between a normal fun and a suspend fun is quite different, with the latter being translated into a state machine

[Peter Ertl]

so will runBlocking do harm besides losing track of the coroutine state? I am using 3rd party code that is not aware of suspend and I need to put my async stuff in there.

[ephemient]

losing coroutine context means losing structured concurrency

[Peter Ertl]

a damn - so coroutineScope { } will not work anymore?

[Peter Ertl]

that explains a lot

[ephemient]

the scope inside runBlocking will not have any relation to whatever was outside of it

[Peter Ertl]

I am using kotlin exposed and the transaction call does not support suspend

[Peter Ertl]

that’s the whole problem

[Peter Ertl]

so I have to somehow move the suspend logic outside of the db transaction I guess

[ephemient]

if you have an async api available, Kotlin's job/deferred types can be adapted to futures/rx types

[ephemient]

but if there's no async api, then this is a pain whether you're using Kotlin or not

[Peter Ertl]

yeah .. I see .. jdbc not being async is the root of all evil

[Peter Ertl]

lol

[Peter Ertl]

and we have no async driver for oracle here

[Peter Ertl]

thanks for your advice: I really learnt a lot