Summary

There could be a deadlock risk with the original implementation. Consider the following execution sequence:

1. Assume both of threads T1 and T2 get the runner read locks, which contains None.
2. T1 get the write runner lock, and create a runner.
3. T1 get the read runner lock and run runner.call_async, which yields to js loaders.
4. One of the js loaders call loaderContext.importModule and append a task to module_executor in (assumed) T3. So T1 should wait for T3.
5. T3 will also run their js loaders. Assume T2 request the runner write lock before T3 request runner read lock. Due to the priority policy of tokio::sync::RwLock (https://docs.rs/tokio/latest/tokio/sync/struct.RwLock.html), T3 will not get the read lock before T2 get the write lock.
6. While T1 is holding the read lock, T2 is pending and cannot get the write lock.
7. In conclusion: T1 waits for T3 because of (importModule), T2 waits for T1 to release its read lock, T3 waits for T2 to acquire and release the write lock.

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).