Based on what you said in #44 i had a look at function.rs and generator.rs and i don't quite understand how that is going to work async
JavaScript engines typically rely on running in an EventLoop and provide a way to expose jobs which should be added to that loop.
QuickJS has an internal vec of pending jobs accessed by calling JS_IsJobPending() and then JS_ExecutePendingJob() (the downside of this is that you have call those after everything you do with the quickjs runtime).
Spidermonkey has a more elegant solution, you can add a hook (fn/closure) for when an async job has to run (SetJobQueue())
For quickjs I implemented an generic EventLoop here: https://github.com/HiRoFa/utils/blob/master/src/eventloop.rs
For Promises in starlight i was planning to add a simple hook (vm.registerJobAddHookThingy(Fn(Job)) which in turn adds the job to the EventLoop so it wil run async (but in the same thread) but i'm wondering if that's the way you want to go or have an other solution for async jobs...?
Based on what you said in #44 i had a look at function.rs and generator.rs and i don't quite understand how that is going to work async
JavaScript engines typically rely on running in an EventLoop and provide a way to expose jobs which should be added to that loop.
QuickJS has an internal vec of pending jobs accessed by calling JS_IsJobPending() and then JS_ExecutePendingJob() (the downside of this is that you have call those after everything you do with the quickjs runtime).
Spidermonkey has a more elegant solution, you can add a hook (fn/closure) for when an async job has to run (SetJobQueue())
For quickjs I implemented an generic EventLoop here: https://github.com/HiRoFa/utils/blob/master/src/eventloop.rs
For Promises in starlight i was planning to add a simple hook (vm.registerJobAddHookThingy(Fn(Job)) which in turn adds the job to the EventLoop so it wil run async (but in the same thread) but i'm wondering if that's the way you want to go or have an other solution for async jobs...?