I’ve been investigating alternatives to `runBlocking {}`in Kotlin/JS, and I’m wondering something. Correct me if I’m wrong, but the restriction is basically because in JS bridging between blocking/non-blocking requires using

await

, which is only possible inside

async

functions. This is incongruous with JVM and Native, where it’s always possible to block the thread, and no

async function

keyword is required. So, I was thinking. would it be possible for a Kotlin compiler plugin to edit the Kotlin/JS compiler so it generates a

async function

instead of a regular function wherever

runBlocking {}

is used in a Kotlin/JS function?

I think if it was possible to implement

runBlocking

by using async/await it would have been done already. I recall that this discussion for KotlinJS has been going on for quite a while, like years probably

at the moment I’m just curious whether a compiler plugin is able to change the compiled JavaScript code, so Kotlin will compile all Kotlin functions into async functions

The concept of "blocking" doesn't really exist in JS, so there can be no

runBlocking

The concept of “blocking” doesn’t really exist in JS

isn’t

await

effectively the same as

runBlocking {}

? What’s the difference between this JavaScript function

async function blah() {
  const data = await foo()
  return data
}

and this Kotlin function?

fun blah(): String {
  val data = runBlocking { foo() }
  return data
}

No,

await

is the same as calling a

suspend

function normally, or as calling KotlinX.coroutines'

await()

function

that sounds like the same thing to me :)

It really isn't. One of them breaks your entire website, the other lets it run normally.

sorry, I’m not getting what you mean

Let's imagine you have a simple website with a button that does

window.alert("clicked")

When the website loads, you do

GlobalScope.launch {
    delay(10_000)
    window.alert("stopped")
}

If you click on the button, you get the alert immediately. 10 seconds later, the "stopped" alert appears. Now, let's imagine

runBlocking

existed. When the page loads, you do:

runBlocking {
    delay(10_000)
    window.alert("stopped")
}

You click on the button. Nothing happens. After 10 seconds, the "stopped" alter appears. When you close it, the "clicked" alert appears. When you use

runBlocking

, everything else in the page must wait for it to end before anything else can happen.

When you use

runBlocking

, everything else in the page must wait for it to end before anything else can happen.

yes, that’s fine by me, that’s what I want

It's really not what you want. It means each time you do a network call, all buttons in the app stop working until the network call ends.

that’s fine by me

Just have a global

Mutex

then, but seriously your users don't want that

I’m my own user :)

What are you making?

a test utility to load test resources for multiplatform testing over a network. I want to implement the Okio Filesystem, and the functions aren’t marked as

suspend

I don't think that's possible. The browser does not have synchronous APIs to do that. The native APIs are callback/promise based, so you can't use them in regular functions

The native APIs are callback/promise based, so you can’t use them in regular functions

yeah exactly, so I wanted to find out if there’s a way to tell Kotlin/JS to generate async functions

You said you want to implement an interface that is just regular functions? You can't

await

inside of them

that’s true at the Kotlin level, but in JavaScript I don’t think the interface exists

The signature must watch, and it can never be

async

as I understand JavaScript doesn’t have interfaces, though I’m no expert! So as long as the Kotlin code implements the interface, and the JavaScript code works, then it’s okay if the JavaScript code differs and returns a Promise

True, but the JS code will have to be

async

/return a promise. Regular functions in your Kotlin interface must be regular JS functions, so you can't call

async

functions inside of them.

Regular functions in your Kotlin interface must be regular JS functions

but what if a Kotlin compiler plugin added

async

to all generated JavaScript functions?

Then you wouldn't be able to call any Kotlin code in any non-

async

JS function, so you would never be able to do any kind of interop with JS

mmm yes, good point. So what if

async

were added selectively, only where necessary?

How do you know where it is necessary?

even if it was manually, like a

@JsAsync

annotation

You still wouldn't be able to add it to an interface implementation, it would need to be on the interface itself

there’s probably a way to be clever and do some analysis to determine all call routes, but just running it and see if it works would be fine initially

Example:

interface Foo {
    fun foo(): String
]

class FooImpl1 {
    override fun foo(): String = "1"
}

class FooImpl2 {
    @JsAsync
    override fun foo(): String = "2"
}

fun bar(impl: Foo): String {
    return impl.foo()
}

How do you compile

bar

? If the argument is

FooImpl1

, it must be a regular JS function (not

async

), but if the argument is

FooImpl2

, then it must be

async

.

yeah, that’s a good edge case

Same problem. What about common code that calls your implementation? It needs to magically know your implementation is

@JsAsync

and add it to somehow. Which means whenever you add/remove

JsAsync

to any function anywhere, your entire codebase changes signature

the Kotlin/JS compiler needs to know, but the whole application doesn’t need to know, does it?

But that's impossible. The functions that need to be

async

are the functions you want, and all the functions that appear above on the call chain. If at any point you call

list.forEach {
    yourAsyncFunction()
}

then

List.forEach

must be

async

, and therefore all functions that call it must be too. And now, everything has to be

async

.

yeah, that’s right, so the compiler would need to figure out which functions need to be made async. Again, that can either be done in a clever way, or just hard code it

I mean, it's not "figure out", it's the entire codebase. The entire standard library needs to be recompiled just for your project, as well as any other library you use.

how so? I use the stdlib, the stdlib doesn’t use my library

All lambdas passed must be

async

too. All functions you call which accept lambdas must be

async

if you call

async

stuff inside of them, so

forEach

,

filter

,

map

etc need to be

async

as soon as a single of their usage calls

async

in them

sorry, I don’t follow… it wouldn’t be changing the signatures of those functions to change them from

fun operation(block: () -> Unit)

to

fun operation(block: () -> Promise<Unit>)

That's only possible if

map

is

inline

and all executions happen during the execution of the function. In all other cases, this code is wrong.

mmm okay, I think I get it

The problems are: • first solution: you won't be able to call any code, because you'll hit functions like that everywhere in Kotlin • second solution: it's contagious, so all usages of these functions must be converted as well, as well as their usages, etc

yeah, it’s not perfect

But then, you can't call any Kotlin code from any non-async JS code

this is a test util, so it can return

Promise<Unit>