5 ms·

> A very interesting property of the event loop model is that JavaScript, unlike a lot of other languages, never blocks. That seems like a dangerous, misleadin

> A very interesting property of the event loop model is that JavaScript, unlike a lot of other languages, never blocks. That seems like a dangerous, misleading statement.

kyberias 9y ago
Indeed, nothing in Javascript _language_ indicates that is has to be single-threaded. Then the author continues by comparing this with C and talks about threads. Again, nothing in C programming language indicates that it's multi-threaded.
- tyingq 9y ago
  C is low level enough that you can mutex around non thread safe stuff, without big changes to the underlying implementation. I suppose the JS language spec itself doesn't rule out multi-threaded, but I imagine that would be a fairly big endeavor to re-do the guts of any implementation. The current limitations of web workers seems to confirm that.
  - saurik 9y ago
    With a concurrency-safe garbage collector (which isn't even hard to come by) I would argue the exact same is true of JavaScript. It really isn't a language detail and I would argue it would be a weekend project to get real multithreading working for JavaScript (as in, to the point where it works as well as in C, which is to say it might require tons of mutex locks everywhere).
    - pcwalton 9y ago
      It's already been implemented, in fact, in the venerable Rhino JS engine.
    - aardvark179 9y ago
      It can be done, and has been in Rhino, Nashorn, and graal.js. The problem isn't in the language per se but in the libraries provided as standard (mutexes, thread safe hashes/property access etc.) and in the implementation. It's much easier to build a JIT when you don't have to worry about concurrent threads of execution, and converting a single threaded JIT to a robust multithreaded one can take a lot of work.
pcr0 9y ago
Indeed. Any time JavaScript is executing, there is blocking. One has to be really careful to avoid CPU-bound code in JavaScript or all the benefits of the "non-blocking" model go down the drain.
- caleblloyd 9y ago
  I think they meant that there is never blocking I/O
baron816 9y ago
One thing that really helped me understand the JS event loop was that the callback from an asyc call CAN block. Something like setTimeout(() => { var x; while (x < 2000000) { x += 1; } }); will block. Event listeners, timeouts, and xhr requests just wait to receive a response. They're not actually doing anything while that happens. And their callbacks basically just become 'synchronous' when they get that response.
- saurik 9y ago
  I am highly confused as to what you might have thought other than that the callback itself could block... would you mind sharing? (I am an educator and teach a class on programming languages, so my question here is one of some serious interest: to understand the beginner's mindset better.)
  - baron816 9y ago
    I just had a hard time building a mental model of what the asyc function was doing, and the analogy I had heard before made it sound more like a multi-threaded process (something I also didn't fully grasp). The analogy I had heard was that of a check-in window at a doctors office: the nurse would give you a form to fill out and when you were done, you could get back in line and hand the form back to the receptionist. I think the analogy was trying to show that there weren't multiple windows to check in at, nor did you have to stand at the window while you're filling out the form, preventing people behind you from getting the form. But the reason it's a bad analogy, and why I was confused, was that it made it appear that you (the patient) are the callback function, and you're doing some processor intensive work when you sit down to fill out the form. It would have been clearer had the analogy specified that you are actually a backend server/web-worker, but even that doesn't fit right. So, I think it would be best to avoid using analogies. The event loop isn't that complicated: async functions just sit around waiting for a response, and they stick their callback on the event queue when they get that response. When the call the stack is cleared (from it's synchronous functions), the first callback in the event queue moves to the call stack (ie, it gets called), and that process repeats until the queue is cleared.
  - 9y ago
paulddraper 9y ago
Right. Whether it's the browser's XMLHttpRequest or localStorage or NodeJS's readFileSync JS can block on I/O. But since the language is single-threaded (or at least, it defines nothing about multiple threads with shared memory), there is a strong incentive not to have blocking functions.
- jayflux 9y ago
  Synchronous mode for xmlhttprequest has been deprecated now for some time (at least in FF anyway)
  - paulddraper 9y ago
    Sure. But it exists/existed. No magic says that everything in JS has to be non-blocking.

> A very interesting property of the event loop model is that JavaScript, unlike a lot of other languages, never blocks. That seems like a dangerous, misleading statement.

kyberias 9y ago

Indeed, nothing in Javascript _language_ indicates that is has to be single-threaded. Then the author continues by comparing this with C and talks about threads. Again, nothing in C programming language indicates that it's multi-threaded.

tyingq 9y ago
C is low level enough that you can mutex around non thread safe stuff, without big changes to the underlying implementation. I suppose the JS language spec itself doesn't rule out multi-threaded, but I imagine that would be a fairly big endeavor to re-do the guts of any implementation. The current limitations of web workers seems to confirm that.
- saurik 9y ago
  With a concurrency-safe garbage collector (which isn't even hard to come by) I would argue the exact same is true of JavaScript. It really isn't a language detail and I would argue it would be a weekend project to get real multithreading working for JavaScript (as in, to the point where it works as well as in C, which is to say it might require tons of mutex locks everywhere).
  - pcwalton 9y ago
    It's already been implemented, in fact, in the venerable Rhino JS engine.
  - aardvark179 9y ago
    It can be done, and has been in Rhino, Nashorn, and graal.js. The problem isn't in the language per se but in the libraries provided as standard (mutexes, thread safe hashes/property access etc.) and in the implementation. It's much easier to build a JIT when you don't have to worry about concurrent threads of execution, and converting a single threaded JIT to a robust multithreaded one can take a lot of work.

pcr0 9y ago

Indeed. Any time JavaScript is executing, there is blocking. One has to be really careful to avoid CPU-bound code in JavaScript or all the benefits of the "non-blocking" model go down the drain.

caleblloyd 9y ago
I think they meant that there is never blocking I/O

baron816 9y ago

One thing that really helped me understand the JS event loop was that the callback from an asyc call CAN block. Something like setTimeout(() => { var x; while (x < 2000000) { x += 1; } }); will block. Event listeners, timeouts, and xhr requests just wait to receive a response. They're not actually doing anything while that happens. And their callbacks basically just become 'synchronous' when they get that response.

saurik 9y ago
I am highly confused as to what you might have thought other than that the callback itself could block... would you mind sharing? (I am an educator and teach a class on programming languages, so my question here is one of some serious interest: to understand the beginner's mindset better.)
- baron816 9y ago
  I just had a hard time building a mental model of what the asyc function was doing, and the analogy I had heard before made it sound more like a multi-threaded process (something I also didn't fully grasp). The analogy I had heard was that of a check-in window at a doctors office: the nurse would give you a form to fill out and when you were done, you could get back in line and hand the form back to the receptionist. I think the analogy was trying to show that there weren't multiple windows to check in at, nor did you have to stand at the window while you're filling out the form, preventing people behind you from getting the form. But the reason it's a bad analogy, and why I was confused, was that it made it appear that you (the patient) are the callback function, and you're doing some processor intensive work when you sit down to fill out the form. It would have been clearer had the analogy specified that you are actually a backend server/web-worker, but even that doesn't fit right. So, I think it would be best to avoid using analogies. The event loop isn't that complicated: async functions just sit around waiting for a response, and they stick their callback on the event queue when they get that response. When the call the stack is cleared (from it's synchronous functions), the first callback in the event queue moves to the call stack (ie, it gets called), and that process repeats until the queue is cleared.
- 9y ago

paulddraper 9y ago

Right. Whether it's the browser's XMLHttpRequest or localStorage or NodeJS's readFileSync JS can block on I/O. But since the language is single-threaded (or at least, it defines nothing about multiple threads with shared memory), there is a strong incentive not to have blocking functions.

jayflux 9y ago
Synchronous mode for xmlhttprequest has been deprecated now for some time (at least in FF anyway)
- paulddraper 9y ago
  Sure. But it exists/existed. No magic says that everything in JS has to be non-blocking.