Related tangent: Platformatic's "Watt" server^1 takes a pretty interesting approach to Node, leveraging worker threads on all available cores for maximum efficiency.
1. https://docs.platformatic.dev/docs/overview/architecture-ove...
Node.js worker threads are problematic, but they work great for us
11–20 of 35 posts
Re: Node.js worker threads are problematic, but they work great for us
#12[flagged]
[dead]
Re: Node.js worker threads are problematic, but they work great for us
#13I get its a constraint of the language but the ubiquitousness of bundlers and differing toolchains in the JS world has always made me regret trying to use worker primitives, whether they be web workers, worker threads and more. Not to mention trying to ship them to users via a library being a nightmare as mentioned in the article. Almost none of them treat these consistently (if they consider these at all) and all re…
Yea, for the vast, vast majority of workloads just forking separate node process ends up being better than mucking with threads.
Re: Node.js worker threads are problematic, but they work great for us
#14The article calls worker threads "problematic", but it doesn’t really make a strong case for why they’re supposedly problematic.
Having a separate isolate in each threads spawned with the worker threads with a minimal footprint of 10MB does not seem like a high price to pay. It's not like you're going to spawn hundreds of them anyway is it? You will very likely spawn less or as much threads as your CPU cores can handle concurrently. You typically don't run a hundred of threads (OS threads) you use a thread pool and you cap the concurrency by setting a limit of maximum threads to spawn.
This is also how goroutines work under the hood, they are "green threads", an abstraction that operate on top of a much small OS thread pool.
Worker threads have constraints but most of them are intentional, and in many cases desirable.
I’d also add that SharedArrayBuffer doesn’t limit you to “shared counters or coordination primitives”. It’s just raw memory, you could store structured data in it using your own memory layout. There are libraries out there that implement higher-level data structures this way already
Re: Node.js worker threads are problematic, but they work great for us
#15The lack of backpressure handling nor promise api for postMessage is also quite annoying, I had many OOMs because of it.
Re: Node.js worker threads are problematic, but they work great for us
#16The worker situation would be much better with inline workers (or modules).
https://github.com/tc39/proposal-module-declarations
Unfortunately the JS standards folks have refused so far to make this situation better.
Ex. it should just be `new Worker(module { ... })`.
Re: Node.js worker threads are problematic, but they work great for us
#17The article calls worker threads "problematic", but it doesn’t really make a strong case for why they’re supposedly problematic. Having a separate isolate in each threads spawned with the worker threads with a minimal footprint of 10MB does not seem like a high price to pay. It's not like you're going to spawn hundreds of them anyway is it? You will very likely spawn less or as much threads as your CPU cores can hand…
The problematic part is mostly in nomenclature. They’re called “threads” but don’t really behave the way you’d expect threads to.
They’re heavy, they don’t share the entire process memory space (ie can’t reference functions), and I believe their imports are separate from each other (ie reparsed for each worker into its own memory space).
In many ways they’re closer to subprocesses in other languages, with limited shared memory.
It’s not “clean” to spin up thousands of threads, but it does work and sometimes it’s easier to write and reason about than a whole pipeline of distributing work to worked threads. I probably wouldn’t do it in a server, but in a CLI I would totally do something like spawn a thread for each file a user wants to analyze and let the OS do task scheduling for me. If they give me a thousand files, they get a thousand threads. That overhead is pretty minimal with OS threads (on Linux, Windows is a different beast).
Re: Node.js worker threads are problematic, but they work great for us
#18[dead]
Re: Node.js worker threads are problematic, but they work great for us
#19Or you could use Elixir with Postgrest and not have to bold on all this wonky 3rd paid tools for basic stuff like background jobs:
Re: Node.js worker threads are problematic, but they work great for us
#20I like Node.js' simple and fully isolated concurrency model. You shouldn't be blocking the main event loop for 30 seconds! The main event loop is not intended to be used for heavy processing. You can just set up a separate child process for that. The main event loop which handles connections should just co-ordinate and delegate work to other programs and processes. It can await for them to complete asynchronously; th…
You like limitations, which is ok, I'll take a better toolset.
You can not limit yourself when you need more but still follow these patterns in any other language.