> 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 tempora

> 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.