Hacker News Reader

Comment by drderidder | Hacker News Reader

It's a widely held misconception that JS doesn't have threading. User code executes in a single thread, but asynchronous tasks are managed by a thread pool (libuv in node). Because the multi-threading is hidden with asynchronous calls, the user doesn't need to worry about it, which is why many people say JS is single-threaded. In fact worker threads execute async tasks behind the scenes; it's a very nice feature of the event-loop architecture.

View on HN

You may be speaking of a particular implementation or engine. JS, the language, has no such concept of a "thread". The standard describes execution of a valid program as linear. Libraries may add functions such as event listeners or threading or sockets, but these are not part of the language.

And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mozilla, then Node doesn't use that anyway :p

Well, there are Web Workers, which are basically threads. http://www.html5rocks.com/en/tutorials/workers/basics/

But it appears that it's part of the WHATWG HTML spec rather than ECMAScript, which is a bit weird.

That's because it's a Web platform API, not a language feature.

Web Workers are closer to "processes" in the Erlang sense of the term. They're walled off fairly extensively from the rest of the JS runtime that spawned them because that is pretty much the only good way to backport threading onto a language that wasn't designed with it in mind from the beginning.

Languages like C which had them bodged on years later, well, I'd call that a bad way to do it. It worked for the time but there's a reason why we are all fleeing that implementation of threading and it still stains the entire idea of "multithreading" decades later.

If JS is ever going to get threading, the best case scenario is for it to look like Perl or PHP's efforts... years and years of implementation work to get to something that pretty much everybody recommends you still just stay away from. And Perl and PHP were trying to integrate threading into just one runtime each, and without a browser connected at the hip with its own ideas about threading embedded into decades of code. I would not hold your breath for "true" JS threads anytime soon.

Timers are sort of threads..

Let me know if you disagree... Don't just hide behind a down vote...

Really? I've never seen any synchronization code (e.g., locks) in JavaScript. If multiple threads can execute async tasks in parallel, doesn't that mean JavaScript needs synchronization primitives? Most JS code I've seen in the wild relies implicitly on the single-threaded assumption—that only one callback (for example) will run at a time.

Say you wanna make an HTTP request.

What node will do is kick off the process (dns, grab a socket, connect tcp, write the header, wait for response etc.)... but it won't wait for any of this to finish, it just starts it on another thread. That thread doesn't need any JS-level synchronization because it has nothing to do with JS. Furthermore, you can kick off multiple requests like this in parallel.

When a request is done and has data to pass back, the external thread will queue up a V8 event. When V8 is free and is ready for the next event, it will see the finished request and trigger your callback with the data. When you're done handling that data (in Javascipt), V8 will wait for the next event and so on.

So you see, it's parallel but doesn't need any JS synchronizatioon.

How much time in a typical Node application is spent executing JS, vs. how much is in the C++ networking code?

> the external thread will queue up a V8 event

> So you see, it's parallel but doesn't need any JS synchronizatioon.

I don't know much about V8/Node internals, but I think we can regard the queue as a synchronization primitive? Granted, from what you say it's not in JS, but it's there, so at least some JS implementations need synchronization.

This is not done in parallel. Only one block of javascript is being executed at any given time. There is also no concept of preemption, if your function runs forever no other other events or callbacks will be handled.

JavaScript does not share memory between threads. No shared memory - no need for sync code. Instead it uses message passing and event loop to do the sync for you.

The way it's implemented is similar to Windows 3.x times - collaborative multitasking. Then there is no code to execute in your thread, an background event loop runs, listens for messages from another threads and calls appropriate callback function in your thread.

This design has the benefit of being simple to do simple stuff. And near impossible for more complex multithreaded algorithms that require shared memory.

Sorta. What you say it true, but it is also true that Node isn't multi-threaded because the user does not have access to that thread pool. The user cannot create their own threads to do CPU work unless they go into C/C++ land. In other words, only I/O is multi-threaded so if you need to do expensive CPU work then you need to spawn a process which can be cumbersome.

Just to clarify this was responding to:

> I thought that they intentionally choose javascript because it doesn't have any features like threading.

I wanted to point out that JS doesn't preclude parallelism, it's just implemented as async calls. It would be more correct to say the runtime owns the thread pool. Thanks to other commenters for making the distinction.

Does each thread get a separate V8 interpreter? I was pretty sure that V8 has a GIL (at least at the Isolate level), just like Python and (Matz) Ruby, and so how do they handle lock contention between multiple threads?

No, because the I/O threads never enter JS land (V8); they just dump their data for the main V8 thread to pick up.

And yes you are correct that V8 effectively has a GIL for its Javascript execution (though V8 does actually run other threads in the background for profiling).

But for web workers there are two threads executing JavaScript in parallel no? However they cannot share state. They can only communicate via messages. It's basically the actor model and it does demonstrate how effective and safe it can be (although Erlang already demonstrated that in spades). No pure FP needed! (although in theory I suppose you could deadlock with two workers waiting on each other for a message)

Is that a language feature or a runtime/library feature though?

The language is designed to handle events/messages because it runs on single thread in the browser. As far as I know, you cannot spawn threads.

The runtime/library does it under the hood.

Reply on news.ycombinator.com