Hi Mike, On Mon, Apr 18, 2011 at 12:00 PM, Mike Meyer <mwm@mired.org> wrote:
It's useful to use non-determinism (i.e. concurrency) to model a server processing multiple requests. Since requests are independent and shouldn't impact each other we'd like to model them as such. This implies some level of concurrency (whether using threads and processes).
But because the requests are independent, you don't need concurrency in this case - parallelism is sufficient. The unix process model works quite well. Compared to a threaded model, this is more robust (if a process breaks, you can kill and restart it without affecting other processes, whereas if a thread breaks, restarting the process and all the threads in it is the only safe option) and scalable (you're already doing ipc, so moving processes onto more systems is easy, and trivial if you design for it). The events handled by a single process are simple enough that your callback/event spaghetti can line up in nice, straight strands.
Threads and processes are both concurrent programming models. You get parallelism if you map the threads/processes to more than one CPU core. Processes (and to some extents threads) only scale (well) horizontally; given more processes you can handle more concurrent requests. However, they don't scale vertically, given more processes you don't handle a particular request any faster*. Since GHC's scheduler deals with both CPU bound threads and I/O bound threads you can use it to process single requests faster. A typically CPU bound activity is page rendering, which you could break up like this: renderPage = firstPart `par` secondPart `pseq` combine firstPart secondPart where firstPart = render ... secondPart = render ... This would run in GHC's per CPU core thread pool, if there are free CPU resources to do so. Regarding robustness I think Simon covered most of that. GHC's RTS gives you the building blocks you need to write Erland style process monitoring/restart. * In theory you could use IPC to implement parallel algorithms using processes, but it's hard to achieve real world performance gains this way as the overhead is quite large. Johan