4 ms·

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 t

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.

Galanwe 6y ago
> 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.