Thread safety in JS?

[Domi]

Is JS absolutely thread-safe? That would kinda require that everything you do would be executed in the same thread.
When using Ajax, you automatically have more than one thread but how does JS handle that? Might it execute code from different threads at once or can I be sure that all the Ajax-responses will be invoked upon the GUI thread?

[evant]

A quick google search seems to indicate that javascript implementations are single threaded.

[Animal]

There are no threads in the current browser implementations of javascript.

There is asynchronous processing, but javascript code only executes in one thread.

[mystix]

:-? just read on userjs.org though that each call to setTimeout() starts a new thread:
http://userjs.org/help/tutorials/efficient-code

see the section titled "Timers take too much time".

i believe this would be the sole exception to the current single-threaded js rule.

[jay@moduscreate.com]

Excellent article.

I like this: "Additionally, timers are in the eval family of methods, making them doubly inefficient."

[Animal]

I'm not sure it's strictly what a Java programmer would think of as a thread. That is potential concurrent access to objects. It's like a thread. I think the javascript thread is interrupted when a timeout expires and its function runs.

Also, it says that setTimeout is like eval. Not really. Only if you use it with a string argument which is then evaluated.

[jay@moduscreate.com]

i guess threads would mean starting processes in the background and possibly priority for those 'threads'?

[Domi]

Ok thanks for the insight. On that day, I googled once for "thread safety in js" which did not return anything... I should have tried a broader search :)



i guess threads would mean starting processes in the background and possibly priority for those 'threads'?


Threads and processes are different from each other, so it would not really fit to say that with each thread a process is started.
And what about priorities?

Furthermore the text on userjs.org says:


setInterval and setTimeout are commonly used to provide animation effects. Each one requires an additional thread to be created for each timeout, and when browsers try to run several timeout threads simultaneously, they slow down.


Well, if one timer needs exactly one thread then I would call it a bad implementation by the browser (and I guess, browsers handle this differently). Usually timers are not single threads, unless they have to be very precise. Else its enough to have one thread for all timers. And even if it was one thread per timer - threads do not slow down: Synchronizing threads does.
I did not do any performance tests, but still timers seem to be pretty slow in most browsers. That must have something to do with the fact that everything (as I learnt now) must be invoked on the JS main thread - to ensure the highly welcomed ultimate thread-safety. That costs a lot of performance but also makes coding a lot less troublesome.

Other than that, its a good text with quite useful tips on how to write cleaner code. Thanks for sharing, mystix!

[jay@moduscreate.com]

sorry, instead of process i shoul dhave said 'function' or 'method'