Closed CheatCod closed 1 year ago
My theory is that the proper way to fix this issue is to dedicate a thread to each Deno main worker. However, this seems resource-intensive and wasteful, as every macro invocation will allocate a system thread. Having multiple Deno main workers share a thread with a tokio runtime would be preferable, but issues arise when a thread is saturated with running synchronous JS code while attempting to run another main worker.
The current implemented solution involves the MacroExecutor keeping a constant number of threads internally, and randomly distributing macro invocations across the thread to reduce the chance of this issue. This solution is not perfect as it is theoretically possible to saturate all the threads with long-running sync js code, let's just hope this isn't a common use case for the end user.
Another potential solution is to block_on
the execution of synchronous js code, this may be the best solution but I will have to test more.
Closed. Every Deno main worker now has its own thread
Intention:
Why is it necessary: