I am trying to list the times in which it is useful to run some code in a separate process. Does the following short list cover it?
Speed: the obvious one.
- Multiprocess/distributed parallism
- Worker process, vs GUI process for responsiveness of UI etc
- No shared-memory space decreases attack vectors
- Part of (but not all of) sandboxing
Ability to interrupt on time out: This is a bit of a hack
- Rather than filling all code with checks to see if have hit a time out condition, run it in its own process, and have a watch dog timer in the main process, which will trigger and interrupt vis SIGINT or failing that SIGKILL on the process doing the work after a timeout.
- Sometimes you find youself needing to use a library this is not reliable.
- You can wrap that library into its own (actor) process
- For example:
- it might leak memory internally: solvable by restarting the process c
- It might on certain corner-cases just segfault. Running it in its own process lets it crash without bringing down the whole process. So you can fail gracefully or restart the wrapper process.
- Obviously one wish to avoid that by replacing the library. But one can't always do that immediately. And sometimes as a bussiness decision it might not be worth it.
- some tools are entire programs that are run on the commandline via. Obviously they run in their own process
Does that cover all the cases?