Hi Mike,
On Mon, Apr 18, 2011 at 12:00 PM, Mike Meyer <m...@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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
