No it doesn’t. We’ve had good models for concurrency in single-threaded systems for a while now.

You say no it doesn't and then speak about concurrency models for single-threaded systems. Choose one :)

Node can't not be single-threaded. Because Javascript is. Node.js is single threaded. It has a single event loop in a single thread, and all the "concurrency" is simply queued on that loop. It offloads some tasks to libuv for some system-related tasks but that's it. And the thread pool that libuv creates is very limited.

Anything that doesn't end up in libuv (that is, probably vast majority of user code) will only ever run in one thread... because Javascript is single-threaded hence V8 is single-threaded hence Node.js you get the gist.

And of course, node.js even has a separate documentation section titled "Don't Block the Event Loop (or the Worker Pool)" [1] because it's trivial to block the event loop.

[1] https://nodejs.org/en/docs/guides/dont-block-the-event-loop/

Not OP, but… concurrency is not the same as parallelism. This is an important hair to split:

https://stackoverflow.com/a/24684037/1026671

"Concurrency" doesn't warrant scare quotes even when describing a single threaded program.

It's true that Node.js allows one task to block many others, but that's an implementation detail of Node.js, not a guaranteed result which necessarily applies to any program using only one OS thread. Other programs suffer from analogous starvation/deadlock/livelock/priority inversion problems, but those would be implementation details too, not guaranteed results from using multiple OS threads.

I never said anything about other programs. I never said that other single-threaded programs don't suffer from the same problems. That's is sort of the point. Node.js is single-threaded and, as a result, had all the same problems a single-threaded programs has. And no amount of hand-waving can change that fact.

You’re focusing on single-threadedness like that’s a problem but it’s not. For example, you can run multiple processes on a single core system just fine — even if one of those processes hangs.

AFAIK there’s nothing in the JS language that forces a single-threaded implementation. I think the real reasons that Node is single threaded are a) legacy and more importantly b) a lot of existing code would break if events were dispatched in parallel.

> you can run multiple processes on a single core system just fine — even if one of those processes hangs.

Yes, I can. Node.js doesn't do that.

The model being "don't do that".

Nodejs has an event loop running in a single thread, but most calls you'll do will be async (and therefore let other operations continue to be executed by the event loop). The entire programming ecosystem is async by default.

The only thing I can think of where a programmer could "easily" block the event loop would be if they explicitly use sync filesystem or other blocking calls instead of the async API. But in any project with reasonable code review I don't think this would happen.

> The only thing I can think of where a programmer could "easily" block the event loop would be

Parsing JSON. Or executing a regex. Or anything, really, that blocks the thread: https://nodejs.org/en/docs/guides/dont-block-the-event-loop/

There's no magic

Well it's a question of magnitude. In theory everything blocks the loop even if it's only 1 CPU cycle before it yields.

In practice I've rarely seen production nodejs applications cause significant CPU blocking issues. Huge JSON parses sometimes, yes, but then it has to be one hell of a payload to cause any significant issue.

Regexes? Have you really seen regexes block CPU for significant time relative to the rest of the application? I'm sure it's possible with a crazy enough runaway pattern, but I've never seen it happen.

I really don't understand what people are getting at here. Nodejs is an async programming model, it's non-blocking by default. Are the people saying it's trivial to break nodejs developers?

My original response was to this [1]

> I think it's much easier to block a thread with C#'s async programming model than node's...

Which spawned a discussion in which people seemingly think that you can't block a thread in node, or that since node is async it means it's not single-threaded etc.

Since it is single-threaded, it's quite possible that the original post wouldn't need 4000 node instances otherwise (emphasis mine):

> We were running 4,000 Node containers (or "workers") for our bank integration service. The service was originally designed such that each worker would process only a single request at a time. This design lessened the impact of integrations that accidentally blocked the event loop

[1] https://news.ycombinator.com/item?id=21782591