Switch from processes to threads
I understand that this is a long-term change, and I also understand that it may involve personal design preferences, so feel free to close it if you do not agree.
Benefits from the change:
- Simplifies overall code, as it would let remove all the shm* api (which by the way is a bit obscure: returning a pointer to
1?) Reduces the clients overhead, where usually the ipc stuff is completely unneeded
- Increases performance (if well designed), reducing memory usage and synchonization times
Drawbacks from the change:
- Processes are safer because they run in its own virtual address space. A process crash doesn't necessarily crash the whole application. A thread crash in the master would be fatal.
- Processes are more secure, because an attack would only compromise one process, not necessarily the whole app.
All in all, I think that the benefits beat the drawbacks.
#1 Updated by Alistair Leslie-Hughes over 7 years ago
I have to disagree. I've been trying to port natively to windows, and this was my initial thoughts as well.
The current approach using processes is more robust. The main issue is if a thread crashes, it will bring down the whole program, as a service this isn't acceptable. Its properly better to spawn a process then have the child process create threads as needed. In this case we can recover from the process crashing, and create a new one.
Some well known examples that use this approach are Apache/Postgres (both run on Window/Linux), there is properly more but these are the only two that I've looked at.
I agree that we need to remove the shm API, since it a pain to do on windows natively, but a better approach might to use a database (sqlite, postgres or mysql) as a way to share non-critical information between processes. Then using shared memory only where is critical for process to share information. for example, number of threads a child is allowed to have.
#2 Updated by Ruben Lopez over 7 years ago
I agree that processes are more robust. And of course an hybrid with processes/threads would be great. Anyway, my main motivation when requesting this change was the point of view of the clients, where all the shm stuff (although partially hidden) is overhelming, and if not managed properly (ie: shm leaks) can cause severe problems, quite difficult to manage.
Then, I want to vote (again) for ticket #132, which will apparently bring more benefits than I initially thought.