The writing is quite confusing - a "coroutine" is by definition cooperative (that's what the "co" means). I understand that this introduces a kind of user-space/green threading (as opposed to OS threads) but it's not clear if they're actually coroutines (can they suspend themselves/yield? Or is it purely preemptive?).
Some notes on the preemption mechanism would be cool too. One of the classic problems with a purely cooperative multitasking system is that the coroutines can become starved in hot loops. Iirc go fixed this by adding preemption using a timer. I've seen some applications use interrupts for this in embedded, but those are expensive too.
Since Melag seems to be an interpreted language embedded in C, it would be very useful to compare it with established alternatives, first of all, Lua (has coroutines) and QuickJS (has async generators and promises).
My understanding is that in Lua and JS coroutines are cooperative, and in Melang, preemptive: this is the key advantage.
Tcl is another well-established language which has had full coroutine support for 10 years now. As with Lua, a Tcl coroutine has to explicitly yield for execution to switch to another coroutine. I would not see preemptive scheduling of coroutines as an advantage, it opens up all the unsafe concurrency issues you get with threads, but without getting threads' advantage of running on multiple cores to compensate. Coroutines in Tcl also integrate cleanly with the existing event system, this allows writing event-driven code without the awkwardness of control inversion, also known as callback hell.
I implemented a 1:M:N userspace lightweight thread scheduler which has 3 types of threads. 1 scheduler thread, M kernel threads and N lightweight threads.
The scheduler preempts the kernel threads and lightweight threads to switch processing between them and uses timeslices.
I wonder if I can integrate coroutine support as I'm not sure what the difference between a coroutine and a lightweight thread is.
How does it preempt?
I set the for loops and while loops to their limit from the scheduler thread! This ends hot loops!
Some notes on the preemption mechanism would be cool too. One of the classic problems with a purely cooperative multitasking system is that the coroutines can become starved in hot loops. Iirc go fixed this by adding preemption using a timer. I've seen some applications use interrupts for this in embedded, but those are expensive too.