In addition to the reasons others have already covered here, most operating systems have relatively expensive process forking--whereas threads can (and have bee

In addition to the reasons others have already covered here, most operating systems have relatively expensive process forking--whereas threads can (and have been) implemented entirely in userspace. So, if your program settled on a model of one "process" per connection, you could rapidly run into slowdowns for forking/execing, and you could also make the OS really unhappy with the number of processes running around. Instead, using threads, the "process" lives only in application code, and you can have as many or as few as you'd like, and the OS really won't care. This, plus all of the usual points about shared memory, easier ownership and communication, simpler programming model, etc. etc. There are use cases for all the options--OS-level processes, heavy threads ala pthreads, green threads ala JVM, and fibers ala custom engine code and Erlang.