4 ms·

JavaScript is (notionally) "single threaded", you can block with just a busy loop; that's not a language change. It's bad design to block, which I expect is wha

JavaScript is (notionally) "single threaded", you can block with just a busy loop; that's not a language change. It's bad design to block, which I expect is what you mean, but that's not a language problem. If you did so in a Worker, you'd have your "don't block the UI thread" in there too.

Dylan16807 1y ago
If you busy loop waiting for something in javascript, your program dies. They're not just a bad idea, they're a non-option. Blocking in the sense of blocking I/O or blocking on a system call is not possible in javascript. So again I ask what you have in mind for a "block on promise" call. The ideas that come to my mind all require significant redesigns of the execution model, or copping out by making every function async and treating it like an await. In particular with workers in mind, I'll put it this way: If you don't allow "block on promise" in the main thread, you generally avoid these issues, but you also don't solve the problem, you still have async versus not async causing many headaches. If you do allow it on the main thread, how do you keep your page functioning? I can imagine resolutions but they all have severe compromises.
- dwattttt 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. 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.

Dylan16807 1y ago

If you busy loop waiting for something in javascript, your program dies. They're not just a bad idea, they're a non-option. Blocking in the sense of blocking I/O or blocking on a system call is not possible in javascript. So again I ask what you have in mind for a "block on promise" call. The ideas that come to my mind all require significant redesigns of the execution model, or copping out by making every function async and treating it like an await. In particular with workers in mind, I'll put it this way: If you don't allow "block on promise" in the main thread, you generally avoid these issues, but you also don't solve the problem, you still have async versus not async causing many headaches. If you do allow it on the main thread, how do you keep your page functioning? I can imagine resolutions but they all have severe compromises.

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