2 ms·

Every time you call a JS function, it's blocking; if it internally busy-looped, you'll die just as much as if you do the loop yourself. Being able to block on

Every time you call a JS function, it's blocking; if it internally busy-looped, you'll die just as much as if you do the loop yourself. Being able to block on an async function call is just as much of a risk; if it returns quick, you live, if it returns slow, you die. The solution to "main page unresponsive, terminate page?" is to always return promptly to the Runtime, so e.g. make everything async. But JavaScript is a language, and it doesn't just exist on web page main threads. As much as JS's proliferation everywhere else isn't my cup of tea, a blocking call in a JS cli tool is what you want. EDIT: I guess to be explicit: > So again I ask what you have in mind for a "block on promise" call I expect it to have the same guarantees and risks of calling a non-async JS function.

Dylan16807 1y ago
> Every time you call a JS function, it's blocking; if it internally busy-looped, you'll die just as much as if you do the loop yourself. But in a very temporary way. If it takes seconds that's a bug, while if blocking I/O takes seconds that's normal behavior. And I've never seen a javascript busy loop in non-malicious code. > I expect it to have the same guarantees and risks of calling a non-async JS function. The main guarantee is that the function will be done and have all its temporary data cleaned up before your (non-worker) execution switches to other code. And in practice you can expect it to return within .1 seconds. That guarantee is going to be an issue if you try to introduce some kind of "block on promise". And the timing expectation is meaningful too.