why Javascript SetTimeout() is not multithreaded

Question

I have a test:

Html:

Empty
Empty

​

js:

var s1 =         


        

Answer 1

After waiting for the given amount of time, The execution for the methods (s1, s2) still happen in the javascript thread itself (which is single threaded).

The reason why s2 waits for s1.

Answer 2

Javascript don't support multithreading because the your interpreter in the browser is a single thread

Answer 3

JavaScript is not multithreaded, but even if it were setTimeout is a synchronous. setTimeout and setInterval are supplied by browsers outside of the proper JavaScript language, which provides an external means of access to the language, like event execution. When people refer to JavaScript as an asynchronous or multithreaded language this is likely what they are referring to because multiple external access points, such as numerous timers or event executions, can occur simultaneously each spawning a unique access point to the interpreter in memory. This is exactly what the developers of Node.js are referring to when they make such claims about JavaScript.

This means of multiple external access to various isolated threads can cause collisions in the UI, because a simulated multithreaded effect will likely cause collisions in browser output where there is only a single document object representing the entirety of a page. This is why setInterval with a short interval is generally deemed unsafe. setInterval is entirely asynchronous and will execute according to the interval provided even if execution in the prior interval has not concluded. This kind of collision is what I call fallover because the next interval is executing code that is falling over the prior execution and if your code requires access to the DOM or uses closures you will likely have problems. For safety a recursive setTimeout is recommended, because it is synchronous and the next round of execution will not occur until the prior has completed.

Answer 4

Javascript is not multi threaded.

HTML5 will give javascript multithread capabilities.

Answer 5

eicto, setTimeout doesn't fire code when requested.
It queues code, inline, with ALL of the other code that comes before it, but it sets its place in line to be at minimum the time requested.

Moreover, most browsers have hard limits for minimum timeouts.
If you request a 1ms timeout, chances are good that in most browsers, you're going to get your request back 10ms-15ms later.

All of the JS interaction with the DOM, and, in reality, pretty much everything a single page does, all happens on one thread, with certain exceptions for custom browser extensions, and a few new APIs (like webworkers).

This is why large projects need to be considerate of everything else on the page, and why everything needs to be asynchronous.

Because setTimeout isn't a sleep and it doesn't return on the exact microsecond that it was croned in for... ...it puts a callback on the event stack, for a time no earlier than what you specify.

Answer 6

Javascript is not multithreaded nor non-multithreaded per se. However, the specific implementations of Javascript that currently are implemented in major browsers mostly ARE single-threaded.

In addition, for proper multithreading, the language needs to have facilities for shared memory, locks, semaphors and other concurrent programming tools, which JavaScript as is currently defined does not have (for example, there is no way to describe how concurrent JS threads would control who gets to update DOM objects that are of course, shared since there's only one DOM in a window).

There are attempts to make JS more parallelized - look at web workers, Intel's River Trail, Google's HTML5 work and more.