Skip to content

[work in progress] Coroutines the Third #12168

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 247 commits into
base: development
Choose a base branch
from

Conversation

Aidan63
Copy link
Contributor

@Aidan63 Aidan63 commented Apr 12, 2025

Third times the charm, right?

This is an evolution of #11554, the core state machine transformation has remained pretty much untouched from that branch, but the surrounding scaffolding code has been changed to more closely align with kotlin's coroutine implementation. This should hopefully address the issues surrounding continuation, scheduling, and a few others which were discovered in the other PR.

Changes

Coroutine functions are now transformed to accept a Continuation<Any> argument, return Any, and contain the state machine transformation. The continuation argument either holds the state of a paused execution of the coroutine function, or what will be invoked once the coroutine completes. The any return will either be the result of the coroutines execution, or a special token indicating that it's execution has been suspended.

@:coroutine function foo(i:Int):String {}

function foo(i:Int, _hx_continuation:ICoroutine<Any>):Any {}

In addition each coroutine function has a class generated for it. This class implements IContinuation<Any> and stores data related to the execution of a coroutine, this includes, the current state, the result or error, variables accessed across states, and a reference to the continuation which will be invoked once this coroutine completes, essentially creating a chain. The continuation interface contains a resume function which when called resumes execution of the coroutine and is responsible to scheduling the execution of the coroutine into an appropriate thread.

class HxCoro__Main_foo implements IContinuation<Any> {
	public var _hx_result : Any;

	public var _hx_error : Exception;

	public var _hx_state : Int;

	public var _hx_context : CoroutineContext;

	public var _hx_completion : IContinuation<Any>;

	public function resume(result:Any, error:Exception) {
		_hx_result = result;
		_hx_error  = error;

		_hx_context.scheduler.schedule(() -> {
			try {
				var result = Main.foo(0, this);
				if (result is Primitive) {
					return;
				} else {
					_hx_completion.resume(result, null);
				}
			} catch (exn:Exception) {
				_hx_completion.resume(null, exn);
			}
		});
	}
}

Coroutines can be started with the blocking function Coroutine.run, which blocks until a coroutine completes. Internally it has its own event loop which all coroutine continuations are scheduled onto.

A quick hello world example is provided below. It should work on all sys targets, but some targets might need their generators updated.

import haxe.coro.Coroutine;
import haxe.coro.Coroutine.delay;

@:coroutine function test() {
    fancyPrint('hello');

    delay(1000);

    fancyPrint('world');
}

@:coroutine function fancyPrint(text:String):Void {
    for (i in 0...text.length) {
        Sys.print(text.charAt(i));

        delay(100);
    }

    Sys.print('\n');
}

function main() {
    Coroutine.run(test);
}

Resources

I'm putting a few links below, specifically related to kotlin's coroutines, which helped the puzzle come together a bit for me.

https://kt.academy/article/cc-under-the-hood

That is a good overview of the underlying machinery of kotlin's coroutines. Jumping straight into decompiled kotlin is very daunting as there are many, many layers of abstraction due to optimisations, features, etc. That article cuts through all of it and gets right to the core of whats happening. I pretty much copied that for this coroutine attempt.

https://www.droidcon.com/2022/09/22/design-of-kotlin-coroutines/

This then goes one layer deper, it covers a lot of those layers you see in kotlin's implementation and explains what they're there for.

https://github.com/JetBrains/kotlin/blob/master/compiler/backend/src/org/jetbrains/kotlin/codegen/coroutines/coroutines-codegen.md

Finally, the mega document. Goes in depth into the jvm codegen of kotlin's coroutines.

Simn and others added 30 commits April 27, 2025 06:59
* Update stack item just before suspension

* class field and local func stack items

* wrap thrown exceptions in a CoroutineException

* bung the exception stack in the result field

* remove commented out code

* move buildCallStack to end of function

* add takeExceptionCallStack

* unbreak CI

* fix some types

* don't let null_pos mess up JVM codegen positions

* change while to if

* ignore for now

broken by the CoroutineException wrapping

* get it working on JVM

* how could I forget about Flash

* coroStack can be null

* make it work on eval

* apparently that can raise

* move top stack handling to BlockingContinuation

this way it works for immediate exceptions too

* remove _hx_stackItem, work with _hx_result directly

* remove CoroutineException, modify error.stack directly

* move texpr builder to context

* embrace the builder

* even more builder

* update __exceptionStack when setting the stack

this should allow reentrancy with regards to exceptions

* add something resembling a test

* overdesign test case

* disable hxb roundtrip for now because that must be an unrelated haxe problem

* this won't work in throw-mode

* make call stack tests print more info on failures

* add __customStack assignment to HL

* remove null_pos from our lives

* cpp setting custom stack

* Add forgotten actual stack setting

* hack around top stack problem a bit to test cpp and eval

* Revert "disable hxb roundtrip for now because that must be an unrelated haxe problem"

This reverts commit d78590d.

---------

Co-authored-by: Simon Krajewski <[email protected]>
we just want to know if this even compiles
* [nullsafety] Allow statics init in main

* usage before init check
)

* haxe/coro: add Mutex typedef for threaded targets, and stub for non threaded targets

* haxe/coro: add body to Mutex stub constructor

* tests: add TestMutex

* more publicity

* fix package

* try to make doc gen happy

---------

Co-authored-by: Simon Krajewski <[email protected]>
* get started on extensible contexts (again)

* introduce Element after all

* more API

* use BalancedTree instead of Array
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants