Proposal: coroutine API instead of cooperative scheduler

[TerensTare]

Since EnTT is using C++20 now, an interesting feature for gamedev is coroutines. EnTT already has a "manual" alternative to them in the form of basic_process, but I would argue it's not the best we can do.

Coroutines allow for a clean way to schedule things to be run each update, freely passing any context around (no need to remember what your void * was exactly), waiting for events to happen, waiting for other "process"-es to finish, etc. Hence, I propose a new API that allows to schedule coroutines to be run each update where you can even bring-your-own coroutine types.

Reference implementation: link.

I would be happy to discuss this more in details and also how this and coroutines work internally. In the code, linear_scheduler and executor<Delta> are separate just so that events don't have to "care" about the delta type.

Note that this implementation is mostly for demonstration purposes and not fully complete yet. Things that are still to discuss/implement are:

• efficient "sleeping" using a priority queue (need to keep track of "elapsed time since creation" in the executor; can also be implemented as a coroutine right now but not as efficient due to context switching)
• custom allocator support for coroutines and the scheduler
• is the process API non-negotiable? it can be emulated for needed cases by using a task<exit_status> at no extra cost

[skypjack]

in the form of basic_process, but I would argue it's not the best we can do

Yeah, definitely 😅 but it was good enough for the purpose in the C++17 era. 💪

I would be happy to discuss this more in details and also how this and coroutines work internally

I'm more than happy to continue the discussion. I haven't had much use for coroutines since they've been around, so feel free to lead the discussion and talk to me like a 3yo. 😅
I also think this could be started as a secondary tool without ditching the existing scheduler. This would allow us to implement it properly and still have an alternative in the meantime.
We need to find another name though, since scheduler is already taken. I'm open to suggestions! 🙂

[TerensTare]

I also think this could be started as a secondary tool without ditching the existing scheduler.

Scheduler can stay around forever. Nothing against it really :).

We need to find another name though, since scheduler is already taken.

How about coro_scheduler? Open to other names too.

I haven't had much use for coroutines since they've been around, so feel free to lead the discussion and talk to me like a 3yo. 😅

I'll attach a document on how they work and why use coroutines, but the best resource really is this blog.
coroutines.md

I'm happy to answer any questions, I know they can be confusing at first since it's a lot of new concepts.

[TerensTare]

So to keep things somewhat similar to the old process API I think one option is to have some action/process/whatever type that can either succeed or fail, along with a "scope" (scheduler) where it executes (I'll explain in a minute). Then we can have the following API:

action action_a();
action action_b();

action action_c(scope &s);
action action_d(scope &s);

// cotrol flow runs just like in a normal sync function
action just_like_sync() {
    co_await action_a();
    co_await action_b();
    // ...
}

action sample_scope(scope &parent) {
    // other scopes discussed below
    // just creates the `race_scope_t` for you, calls the function you passed and waits for the scope to finish on the parent scope
   /*
            so this
            race_scope_t scope;
            lambda_func(scope);
            return await scope.execute_on_parent(parent);
   */
    auto result = co_await race_scope(parent, [](auto &scope) { // scope is race_scope_t or whatever
        // launch your actions here
        action_c(scope);
        action_d(scope);
    });
    co_return result;
}

// depending on what scope is, the execution flow changes
// - sync_scope: just run everything as if you had `await` on every action you launch: finish the first, then go to the next until they all finish. if anything fails this all fails
// - async_scope: run the actions one by one, when one suspends resume the other, just like in a normal scheduler until everything finishes. if anything fails this all fails.
// - fallback_scope: run the first thing syncrhonously, if it fails try the next thing... until one succeeds or everything completes, in which case it fails as nothing was successful
// - race_scope: like async scope, but completes when the first thing completes (no matter success or failure)
// extra (maybe not necessary?): first_to_pass and first_to_fail; like race_scope but on pass/fail respectively, not just completion

So basically scopes are just a way to tell how to execute things. Let me know if this fits with how process worked overall and how you want things to look like, maybe I'm missing some use cases/features.

Also I'm asking on Discord to get feedback from others too.

[skypjack]

Don't worry, I haven't forgotten. I had some demanding stuff at work and I'm off next week, but I should be back on this one after that! 👍 Sorry for the delay.

[TerensTare]

No problem, enjoy the week off :)