Wasm wasi

[igoriakovlev]

This is Wasm-WASI target support for coroutines.

This is based on self-written EventLoop which has a simple implementation for queued line of callbacks with timeouts.

This allows to schedule tasks in scheduler. The EventLoop starts on the program entry-point exit (that supported by the Kotlin from 1.9.23).

The coroutine tests runner implemented with a direct EventLoop call so that looks like the RunBlocking in Native or JVM implementation. We do not RunBlocking itself because there is no design for it in single-threaded environments.

The EventLoop throws an exception EventLoopException which is discussable because it is not supposed to be catched by user in normal code (but still possible for the runTest calls).

[igoriakovlev]

Unfortunately we can't do this in configure-compilation-conventions.gradle.kts because there is no way to distingish WasmWasi target from WasmJs or JS targets there.

[igoriakovlev]

Making this public need consideration.

[dkhalanskyjb]

A typical approach that we take is to take the first throwable, add the other throwables to it as suppressed ones, and then throw the first one. No need for a separate type, the way I understand the problem. Here's an example:

kotlinx.coroutines/kotlinx-coroutines-test/common/src/TestBuilders.kt

Lines 567 to 579 in 0ca7358

	internal fun throwAll(head: Throwable?, other: List<Throwable>) {
	if (head != null) {
	other.forEach { head.addSuppressed(it) }
	throw head
	} else {
	with(other) {
	firstOrNull()?.apply {
	drop(1).forEach { addSuppressed(it) }
	throw this
	}
	}
	}
	}

[dkhalanskyjb]

Why not a private object in CoroutineContext.kt?

[igoriakovlev]

Well, because WasiDispatcher is not a CoroutineContext. But if you would like I will move it.

[dkhalanskyjb]

This seems too mild to me. For example, on Native, we terminate the whole process. On JS, I suppose we use logging only because there's no way to tell JS to stop everything, and even there, we are at least using the error stream, not the standard output. Is there a way to crash the program in WASI or at least make the error seem more scary?

[igoriakovlev]

Well, I put the code which prints an error into error stream and then exit with not 0 error code. I could even send a signal if you would like to have most scariest termination. Please notice - this way all finalisers will not work.

[dkhalanskyjb]

Will @PublishedApi internal with suppresses on the call site also work?

[igoriakovlev]

I prefer not to suppress anything. But if all reviewers ask for this then will do.

[dkhalanskyjb]

Style: boolean parameters should typically be named.

[dkhalanskyjb]

A typical approach that we take is to take the first throwable, add the other throwables to it as suppressed ones, and then throw the first one. No need for a separate type, the way I understand the problem. Here's an example:

kotlinx.coroutines/kotlinx-coroutines-test/common/src/TestBuilders.kt

Lines 567 to 579 in 0ca7358

	internal fun throwAll(head: Throwable?, other: List<Throwable>) {
	if (head != null) {
	other.forEach { head.addSuppressed(it) }
	throw head
	} else {
	with(other) {
	firstOrNull()?.apply {
	drop(1).forEach { addSuppressed(it) }
	throw this
	}
	}
	}
	}

[dkhalanskyjb]

Shouldn't this class be private?

[igoriakovlev]

It used for cancelling in the WasiDispatcher

[dkhalanskyjb]

Event can implement the DisposableHandle interface for this purpose.

[dkhalanskyjb]

Probably better to opt in for the whole file.

[dkhalanskyjb]

A bug: only the last added event will decide whether there are timed events. Adding a timed one first, and then untimed, will lead to the system thinking there are no timed events.

[igoriakovlev]

Ohh, it is true, thanks!!!

[dkhalanskyjb]

If I understand correctly, here's how the event loop implementation works:

• New tasks are added to the queue, remembering the earliest time the tasks should start;
• When the event loop machinery gets its turn, it takes the list of the scheduled events. Then, it waits for the time that it takes for the earliest one to start. Finally, it iterates the list to run all tasks that are due, pushing back the tasks that are not due.

If so, this strategy can lead to incorrect ordering of tasks. Imagine the following scenario.

• There are two tasks: A is scheduled to run in one second, B is scheduled to run in two seconds.
• One second later, A runs for three more seconds and schedules another task, C, to be executed.
• B adds itself to the queue.
• C executes.
• Only then does B execute.

The more robust approach is to use a heap. We have an implementation already in the library. https://github.com/Kotlin/kotlinx.coroutines/blob/0ca735851f0a225b6a7582232a1c9847a27fd059/kotlinx-coroutines-test/common/src/TestCoroutineScheduler.kt uses the heap to implement the event loop for kotlinx-coroutines-test. This implementation isn't long, but can be radically simplified further when there is no multithreading; you don't need to send the "dispatch events", you don't need to use synchronized, etc. You also don't need the separation between foreground and background work.

The main entry point you're interested in is

kotlinx.coroutines/kotlinx-coroutines-test/common/src/TestCoroutineScheduler.kt

Lines 116 to 121 in 0ca7358

	internal fun advanceUntilIdleOr(condition: () -> Boolean) {
	while (true) {
	if (!tryRunNextTaskUnless(condition))
	return
	}
	}

With condition set to { false }. Another change is that here

kotlinx.coroutines/kotlinx-coroutines-test/common/src/TestCoroutineScheduler.kt

Line 96 in 0ca7358

currentTime = event.time

you should actually sleep instead of setting the current time unconditionally.

[igoriakovlev]

If I understand correctly, here's how the event loop implementation works:

Is this a requirement for the implementation? Because there is no tests checking this. And I am not sure that the other implementations, like in JS, are following this.

[dkhalanskyjb]

Yes, this is a requirement. Tests don't check this because, in multithreaded environments, we actually violate this intentionally sometimes. On JS, we don't use our own event loop, we rely on the one provided by the environment.

Now that I look at the implementation more closely, I don't understand the reason to implement new event loop logic at all. We can probably inherit from EventLoopImplBase. For that, we need to implement EventLoopImplPlatform for Wasm/WASI properly. If we go down that path, then, to implement runEventLoop, we can duplicate the logic from

kotlinx.coroutines/kotlinx-coroutines-core/native/src/Builders.kt

Lines 122 to 144 in f9a4545

	fun joinBlocking(): T {
	try {
	eventLoop?.incrementUseCount()
	while (true) {
	var parkNanos: Long
	// Workaround for bug in BE optimizer that cannot eliminate boxing here
	if (eventLoop != null) {
	parkNanos = eventLoop.processNextEvent()
	} else {
	parkNanos = Long.MAX_VALUE
	}
	// note: processNextEvent may lose unpark flag, so check if completed before parking
	if (isCompleted) break
	joinWorker.park(parkNanos / 1000L, true)
	}
	} finally { // paranoia
	eventLoop?.decrementUseCount()
	}
	// now return result
	val state = state.unboxState()
	(state as? CompletedExceptionally)?.let { throw it.cause }
	return state as T
	}

What do you think?

[dkhalanskyjb]

Please change the base of the PR to develop.

[igoriakovlev]

I have rebased onto the master and merged all the AMEND commits by @dkhalanskyjb request.

[dkhalanskyjb]

Please do ./gradlew apiDump; otherwise, the build fails.

[dkhalanskyjb]

Throwing cause here breaks the following test (you can put it in RunTestTest.kt) that passes on the other platforms:

    /**
     * Tests that, when the test scope is cancelled, [runTest] throws that the cancellation exception.
     */
    @Test
    fun testCancellingTestScope() = testResultMap({
        try {
            it()
            fail("unreached")
        } catch (e: CancellationException) {
            // expected
        }
    }) {
        runTest {
            cancel(CancellationException("Oh no", TestException()))
        }
    }

When I do it like this, both the new test and the existing ones pass for me:

    coroutine.getCompletionExceptionOrNull()?.let { throw it }

[dkhalanskyjb]

Let's take a look at this test (which shouldn't be added to the codebase, except maybe as @Ignored):

    @Test
    fun testHappilyHanging() = runTest(timeout = 1.seconds) {
        // launch { // uncomment for the edge case where the job completes but its children don't
        withContext(NonCancellable) {
            println("Start hanging forever")
            Channel<Unit>().receive()
        }
        // }
    }

On the JVM, this test hangs, as expected: there is nothing to obtain from an empty channel, and we ignore the timeout-induced cancellation requests. On Wasm/JS, it fails with "Unknown" after a couple of seconds (ok, weird, but at least the test doesn't pass). On JS, it fails due to the Mocha 2-second timeout.

On WASI, it just exits and reports success. When the event loop has nothing more to do, it just considers the coroutine as finished.

What we can do in this case is platform-specific; for this case, I propose us to do something like

    check(coroutine.isCompleted) { "Coroutine $coroutine did not complete, but the system reached quiescence") }

directly below this line.

[dkhalanskyjb]

Eh, no, it's better to do it in the opposite order. getCompletionExceptionOrNull itself throws exceptions when the coroutine is still active, but really obscure ones.