I'm using a third-party library that implements a ...

# javascript

[loke]

I'm using a third-party library that implements a suspending function (you have to call it in a coroutine scope). When I compile to JS, there is no runBlocking. The JS code in question runs in a webworker, and blocking is not a problem. In fact, I want it to block. Is there some way I can implement a runBlocking that will work in JS? I only care about two usecases for JS: When running as a server using node.js, and when running in a webworker. In both of these cases, blocking is fine.

[ephemient]

even if you say "blocking is fine", it's not possible in JS. there is only one execution thread and if it blocks, nothing else will run

[loke]

Well, there is one way I can think of, and that is firing off another webworker and run it there. Then I can block waiting for the response. That's how I implemented blocking http requests in the webworker.

[loke]

I really don't want to do that again though. It's such a hassle.

[ephemient]

firing off another web worker doesn't share memory so it doesn't match how concurrency works on all other platforms

[loke]

True. So it's more complicated of course.

[ephemient]

you can have a suspend fun main on JS which is pretty close to the top-level async you can get in nodejs

[loke]

I used the shared memory stuff with blocking Atomic instances to implement the blocking file transfer between threads. It was terrible, and I don't want to build something like that again.

[ephemient]

then just make your whole call chain suspend

[loke]

Yeah, if this was a pure JS application, I'd do it that way.

[loke]

Problem is that I'd have to mark everything as suspend. I tried that, but doing so caused a huge performance penalty on the JVM (which is the primary target).

[loke]

Suspend functions on the JVM are quite slow.

[ephemient]

they should not be any slower than non-suspend functions when nothing suspends. if something does suspend, you have to pay that cost regardless

[loke]

It is, because it adds another argument to every function call (the coroutine context)

[loke]

The code I'm working on is a programming language interpreter, and some of the language benchmarks saw a 30% performance reduction when the entire call chain was made suspend.

[loke]

Obviously, for most people, this is not an issue at all. But in an interpreter engine, it's important.

[turansky]

> When running as a server using node.js, and when running in a webworker
Do you process files inside your "blocking" code?

[loke]

Yes, although since I couldn't access any syncronous file access API's from a webworker, I had to emulate it by sending a message to a different thread, and then block until it was done.

[ephemient]

going by those numbers, I'm guessing you're using the host stack for your function calls within your interpreter? that might be the easiest way to build one but threading suspend through such an interpreter sounds like a bad idea

[turansky]

I couldn't access any syncronous file access API's from a webworker

In dedicated web worker we have FileSystemSyncAccessHandle - it's worker specific.

[turansky]

Declarations you can find here 😉