From 38505db39137f33bfdb942658ea892a617ac0980 Mon Sep 17 00:00:00 2001 From: Andreu Botella Date: Sat, 25 Jun 2022 20:56:29 +0200 Subject: fix(modules): Immediately resolve follow-up dyn imports to a dyn imported module (#14958) When a dynamically imported module gets resolved, any code that comes after an await import() to that module will continue running. However, if that is the last code in the evaluation of another dynamically imported module, that second module will not resolve until the next iteration of the event loop, even though it does not depend on the event loop at all. When the event loop is being blocked by a long-running operation, such as a long-running timer, or by an async op that might never end, such as with workers or BroadcastChannels, that will result in the second dynamically imported module not being resolved for a while, or ever. This change fixes this by running the dynamic module loading steps in a loop until no more dynamic modules can be resolved. --- core/modules.rs | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'core/modules.rs') diff --git a/core/modules.rs b/core/modules.rs index 8c4f25d48..e86fdbf73 100644 --- a/core/modules.rs +++ b/core/modules.rs @@ -1803,15 +1803,11 @@ import "/a.js"; ) .unwrap(); - // First poll runs `prepare_load` hook. - assert!(matches!(runtime.poll_event_loop(cx, false), Poll::Pending)); - assert_eq!(prepare_load_count.load(Ordering::Relaxed), 1); - - // Second poll actually loads modules into the isolate. assert!(matches!( runtime.poll_event_loop(cx, false), Poll::Ready(Ok(_)) )); + assert_eq!(prepare_load_count.load(Ordering::Relaxed), 1); assert_eq!(resolve_count.load(Ordering::Relaxed), 7); assert_eq!(load_count.load(Ordering::Relaxed), 1); assert!(matches!( -- cgit v1.2.3