Forking predates threads. It's also makes more sense as a system call, since a library writer can implement spawn() in terms of fork() and exec() but not vice v

Forking predates threads. It's also makes more sense as a system call, since a library writer can implement spawn() in terms of fork() and exec() but not vice versa. It's also still a good model when you want to run N copies of the same code concurrently, since the processes are isolated from each other, making it easier to reason about correctness. There are some wrinkles (primarily due to inherited global state such as filehandles), but they're reasonably well understood (by Unix+C programmers). If you need significant shared state between concurrent paths of execution in the same code, then threads are probably easier.