undefined | Better HN

0 pointsCGamesPlay12y ago0 comments

I already mentioned child processes, which model scaling up to multiple servers better than threads do, are more powerful than web workers, and are supported out-of-the-box with a powerful arbitrary message passing schema including the ability to transfer sockets between processes. It looks like there's some abstractions built around using multiple processes and work queues to help amortize the weight of the additional processes (see node-compute-cluster mentioned elsewhere in this thread), but I've not used anything like this.

0 comments

8 comments · 5 top-level

teacup5012y ago· 2 in thread

> I already mentioned child processes, which model scaling up to multiple servers better than threads do ...

All taking away threads does is eliminate high-value optimization strategies that are available to multi-machine scalable systems that do support threads.

Threads don't dictate shared mutable state as a programming paradigm, they simply make it possible to avoid crossing expensive network and process boundaries where appropriate.

There's nothing stopping you from architecting thread-based architectures to use low-cost in-core dispatch of message within a VM, and save the high-cost serialization, IPC/network overhead for off-machine message dispatch.

memracom12y ago

On which OS is crossing the process boundary expensive?

And how expensive is expensive?

teacup5012y ago

> On which OS is crossing the process boundary expensive?

All of them, always. It's either expensive in terms of resource cost (requiring serialization and complex local IPC overhead), or expensive in terms of complexity (requiring shared memory and inter-process coordination).

rpedela12y ago· 1 in thread

There are threads and processes and both have their pros and cons. Yes it is great that Node has multi-process support out of the box, but what about when threads are a better solution? In my opinion, there is a place for a multi-threading support even if it is not the "Node way".

bcoates12y ago

Short of rewriting the whole system around a threaded model, the only reason to use threads over processes in Node is to make the IPC faster. This means that ultimately supporting threads is an optimization that has to compete for cost-benefit with all the other possible optimizations for Node to support.

yapcguy12y ago

Node's cluster module is handy, but it's a workaround for the fundamental weakness in Node - the entire thing's built on top of a single-threaded event loop which blocks.

Instead of just communicating across threads to do some async busy work, you now have to communicate across processes... along with heartbeat monitoring of those processes and endless debate over which IPC mechanism to use.

jerf12y ago

"which model scaling up to multiple servers better than threads do"

And with that I see you are operating in the Node bubble, where "threads" will forever be stuck in 1995.

It isn't 1995 anymore.

antihero12y ago

Surely you should do things like this in a separate task queue? Use a bunch of node processes for handling taking HTTP requests and spitting out responses, use a different bunch of processes for handling slow things.

j / k navigate · click thread line to collapse