Hacker News Reader

The problem with offloading to a thread is that you can't structurally share data with another thread. So any copying of e.g. arguments can be very expensive, and awkward/inconvenient as well.

If the other thread/process is running on a different machine (or you want to keep that option open) that's what you're going to have to do anyway though.

Yes, but that's a big "if".

Sometimes you want to use a thread to keep the CPU from blocking (e.g. long database operations).

Also, sometimes you want to use the CPU to its full capabilities.

>Sometimes you want to use a thread to keep the CPU from blocking (e.g. long database operations).

On the contrary. That's the prototypical use case for non-blocking event based IO. No threads needed.

>Also, sometimes you want to use the CPU to its full capabilities.

You can use all CPUs by using multiple processes. That's not an issue.

Threads are useful when you want to run multiple algorithms in parallel on the same bigish in-memory data structure, especially one that has a lot of pointers.

Something like an in-memory graph database or a desktop application that lets you work with huge files in-memory, or even complex user interfaces. For instance, I'm not convinced that the cross process bridging that React Native has to do is a great idea.

So yes there are use cases where threads are very beneficial. But on the server side it's essentially the database/analytics systems themselves, not the code that accesses them.

Database access, likely the most common I/O operation from a web server, is certainly running in another process (or on another machine) - I'm not sure that "if" is as big as you suggest.

I agree. But like always, trade-offs.

> The problem with offloading to a thread is that you can't structurally share data with another thread.

That's really a JS issue, not a general async programming issue, though.

> > Does this mean that a web server written in node is running single-threaded?

> Yes.

Just to expand, this (like most things) is a simplification, as I'm sure nitely is just being too brief to explain. It's true for Hello World, and a little further, but real-world web servers in non-trivial contexts typically utilise techniques like clustering, workers, and other ways of delegating tasks to external processes.

>Yes, to take advantage of all CPU cores you have to create more server instances. But why would they talk to the same database instance?

Why not? Unless you've exceeded the capacity of a single DB and have a real use for sharding etc, it would not make sense to have difference DBs (+ replication overhead) for different Node processes.

The parent is asking how comes async I/O can handle higher volumes of requests given it's single threaded and even if it does how comes the database is still not the bottleneck. I answered both of these questions.

Yes, and I had an objection with the answer to the second question, that it might leave the impression to the parent that sharding or replication and pooling is required to have good DB IO performance with multiple Node processes -- when in practice it might or might not be an issue.

You can have a 12-processes node cluster and still not need a second db.