> Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer?
That's true indeed, but I find it more manageable that way.
To me, managing independent processes instead of threads is especially powerful when the lifecycle of the concurrent work can vary.
A typical example that happens quite often is when you have some kind of producer/consumer application. Say, you need to receive some data from a socket, and then process it.
If implemented with threads, it becomes quite messy very fast. You end up with a big blob binary that spawns whatever the hell it wants and need to engineer some complex configuration file to tell it how many workers you want, etc. You also need some notification to this process to tell him to increase or decrease its amount of workers, etc.
With independent process, it can be much more manageable. You can have a "collector" process that reads the socket and places messages in a shared memory, and if you want more/less workers, you just spawn worker processes to read from the shared memory.
You can make exactly this argument the other way around:
If implemented with processes it becomes quite messy very fast. You end up with a bunch of processes that do whatever the hell they want, and need some complex orchestrator script to tell it how many processes you want, and need some notifications to the orchestrator to increase or decrease the number of workers
With threads, you can have a main thread that reads the socket and places messages in a shared queue, and if you want more/less workers you just spawn worker threads to read from the queue.
> if you want more/less workers you just spawn worker threads to read from the queue.
My point is precisely that's its not trivial to do that.
You now need some signal mechanism to tell your main process to spawn or kill workers. That's an additional layer of complexity.
Things get even worse if you want to add new types of workers that were unplanned.
Say I want a new type of worker that is just a forwarder, or a new type of worker that stores the queue on disk for replaying it.
With a monolithic thread based design, you now need to stop your whole main and worker threads and start a newly built process that support these workers.
With a process based design, you just spawn a new worker process and point it to the existing shared memory without any interruption.
That's true indeed, but I find it more manageable that way.
To me, managing independent processes instead of threads is especially powerful when the lifecycle of the concurrent work can vary.
A typical example that happens quite often is when you have some kind of producer/consumer application. Say, you need to receive some data from a socket, and then process it.
If implemented with threads, it becomes quite messy very fast. You end up with a big blob binary that spawns whatever the hell it wants and need to engineer some complex configuration file to tell it how many workers you want, etc. You also need some notification to this process to tell him to increase or decrease its amount of workers, etc.
With independent process, it can be much more manageable. You can have a "collector" process that reads the socket and places messages in a shared memory, and if you want more/less workers, you just spawn worker processes to read from the shared memory.