You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think one simple and useful nodejs compatibility "win" would be to implement setImmediate/clearImmediate. Looking at the code, the "aux jobs" mechanism already seems to implement exactly the semantics of setImmediate (source):
When multiple calls to setImmediate() are made, the callback functions are queued for execution in the order in which they are created. The entire callback queue is processed every event loop iteration. If an immediate timer is queued from inside an executing callback, that timer will not be triggered until the next event loop iteration.
and it is easy enough to make setImmediate available to the goja environment without changing the eventloop implementation, using RunOnLoop. And clearImmediate can probably also be implemented by checking some condition relative to each Immediate on the RunOnLoop callback before calling the JS callback, but this feels like it could be slightly more optimized if we could remove entries from loop.auxJobs instead. Do you think this warrants being part of the eventloop core, or is it best to just implement it outside the package?
The text was updated successfully, but these errors were encountered:
I think one simple and useful nodejs compatibility "win" would be to implement
setImmediate
/clearImmediate
. Looking at the code, the "aux jobs" mechanism already seems to implement exactly the semantics ofsetImmediate
(source):and it is easy enough to make
setImmediate
available to the goja environment without changing the eventloop implementation, usingRunOnLoop
. AndclearImmediate
can probably also be implemented by checking some condition relative to eachImmediate
on theRunOnLoop
callback before calling the JS callback, but this feels like it could be slightly more optimized if we could remove entries fromloop.auxJobs
instead. Do you think this warrants being part of the eventloop core, or is it best to just implement it outside the package?The text was updated successfully, but these errors were encountered: