> In principle, it's possible to support such a scenario by making such an await just "run" the promise to completion. But here you run into issues with how the

> In principle, it's possible to support such a scenario by making such an await just "run" the promise to completion. But here you run into issues with how the runtime handles asynchronous tasks. Is it possible to spin a nested event loop? Not necessarily, it depends on the runtime. If your synchronous call is already on a task (so there's basically an async function on the callstack), you would really want to basically inline all of the function calls so that the await causes the same transformation were it to be called directly in that async function. But such inlining is impossible (due to dynamic function calls). I feel like this touches the point that I'm trying to grasp currently. So, do I understand correctly that in JS land, calling `await` from a non-async function and making that await block until that promise was resolved, would result in a deadlock, because JS is single-threaded? Why do we need a "nested event loop"? Is it because (a) the non-async caller blocks the only thread, and so (b) there's noone else in order to fulfill that promise being awaited on?