13

The following figure is taken from Chapter 3 of the book Secrets of the JavaScript Ninja by Jon Resig. Here the author is explaining the browser event loop.

enter image description here

The book has to say this :

It’s important to note that the browser mechanism that puts the events onto the queue is external to this event loop model. The processing necessary to determine when events have occurred and to push them onto the event queue doesn’t participate in the thread that’s handling the events.

So my question is it correct to say that JavaScript in browser is single threaded? I ask this question because clearly two separate tasks(processing the events and event queing are going on in parallel here).

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Geek
  • 26,489
  • 43
  • 149
  • 227
  • Making above question (maybe) even more interesting might be the implications by so called **immediate callbacks** (as suggested in [this answer](http://stackoverflow.com/a/2734311/1711186)). In short such a **immediate callback** would be Javascript code run, while other code halted by a blocking statement (i.e. `alert()`) has not yet [run to completion](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/EventLoop#.22Run-to-completion.22). By this it seems that the second task "event queuing" can introduce multi-thread problems (i.e. determinism). Good question! – humanityANDpeace Jan 20 '14 at 10:19
  • 1
    possible duplicate of [Is javascript guaranteed to be single-threaded?](http://stackoverflow.com/questions/2734025/is-javascript-guaranteed-to-be-single-threaded) – Liam Jun 16 '15 at 15:34

2 Answers2

11

JavaScript is single-threaded anywhere, in a browser or in NodeJS. It never was supposed to support multithreading in any way (and probably if somebody implements a JS engine with some kind of multithreading, bad things will happen, for sure)

EDIT to answer your edit:

That event queue is filled with data (mouse/kb events, network events, etc) from the main loop of the browser. That same main loop that runs JS. The figure you post is correct but it (kind of) blurs the reality. AFAIK Only one thread handles everything (that is, filling the queue and running, line-by-line, any JS code).

EDIT: One way to prove this: Create a really long loop and a text area. Try to write in the text are while the loop is running. You can't: it's because the main loop is busy running the loop so it can't handle the kb events.

EDIT: This seems to be a really good answer: Is JavaScript guaranteed to be single-threaded?

+2 years after the last EDIT: This answer is getting a little bit old and detached from reality. io.js (and node.js after that, probably Chrom[e|ium], FF, Safari after that) is pushing towards multiprocess support (via workers). You can check more about that here.

Community
  • 1
  • 1
alexandernst
  • 14,352
  • 22
  • 97
  • 197
  • @alexandernst since you quote the [Is javascript guaranteed to be single-threaded?](http://stackoverflow.com/questions/2734025/is-javascript-guaranteed-to-be-single-threaded?rq=1) question I would wonder if you would like to reconsider the statement "AFAIK [...] handles everything (that is, filling the queue and running, **line-by-line**,any JS code)"? The buzzword is **immediate callback** as wisely mentioned in the [toprunning answer of this question](http://stackoverflow.com/a/2734311/1711186). What do you think? – humanityANDpeace Jan 20 '14 at 10:25
  • @humanityANDpeace Indeed that is an interesting read. I'm not really sure how exactly each browser will handle a situation in which you are running a really long block of code and an immediate callback is fired. Anyways, one thing I can assure you: if you relay on this concept, it will backfire, guaranteed. JS is not ment to run any kind/type of multithreading/multiprocess/multiwhatever. – alexandernst Jan 20 '14 at 10:33
  • @alexandernst I did some further checking. Using firefox I can reproduce such "not helpful" behaviour of **immediate callbacks/events** when I use `alert()` to halt some execution. I still wonder if this is just a bug of firefox. Have you happend to read the specs to know what "ought" to be the way of handling concurrency? – humanityANDpeace Jan 20 '14 at 14:16
  • @humanityANDpeace No, I haven't. But my guess is that decent browsers aren't actually pausing the execution of a block of code in the middle on the block just because an immediate callback fired. Think about it this way: Let's say you set an immediate callback to change a global var, and you also use that var inside a large block of code. What will happen if the value of that global variable gets changed while you're running that block of code? (Answer: bad things). – alexandernst Jan 20 '14 at 14:32
  • @alexandernst I am agreeing to your comment very much. I started a question to find out about **immediate events** [here](http://stackoverflow.com/q/21238145/1711186). I think that it is a very bad idead as it would as you suggest break predictability or code execution order. Anyways as a firefox user I can just cause such havoc. Wanna try Firefox + this http://jsfiddle.net/AW8rs/8/ (Instructions: during the alert resize the window). I wonder if I should and how to file a bug. – humanityANDpeace Jan 20 '14 at 15:46
  • @humanityANDpeace Not sure. Maybe try the Chrome/FF bug trackers? https://bugzilla.mozilla.org/ https://code.google.com/p/chromium/issues/list Be sure to include that demo code! – alexandernst Jan 20 '14 at 15:49
  • @alexandernst thank you, I will have a look there. I am not confident they will fix the bug anyways...... Regarding the comment above " JS is not ment to run any kind/type of multithreading/multiprocess/multiwhatever" the introduction of more and more asynchronous functinos like the XHR in compination with the concept of [Promise/A+](http://promises-aplus.github.io/promises-spec/) I think this might be changing. thanks for the discussion! Greetings to Valladolid. – humanityANDpeace Jan 20 '14 at 15:54
0

@alexandernst

One way to prove this: Create a really long loop and a text area. Try to write in the text are while the loop is running. You can't: it's because the main loop is busy running the loop so it can't handle the kb events.

This is happening because the event loop doesn't get to handle the events. If you wait for the loop to complete, you'll find all the text, you wrote while the the loop was running, appear.

That means that you have a separate thread picking up the input events and putting them on the queue.

bungee
  • 61
  • 5