On Mon, 18 Apr 2011 11:07:58 +0200
Johan Tibell <johan.tib...@gmail.com> wrote:
> On Mon, Apr 18, 2011 at 9:13 AM, Mike Meyer <m...@mired.org> wrote:
> > I always looked at it the other way 'round: threading is a hack to
> > deal with system inadequacies like poor shared memory performance or
> > an inability to get events from critical file types.
> >
> > Real processes and event-driven programming provide a more robust,
> > understandable and scalable solutions.
> > <end rant>
>
> We need to keep two things separate: threads as a way to achieve concurrency
> and as a way to achieve parallelism [1].
Absolutely. Especially because you shouldn't have to deal with
concurrency if all you want is parallelism. Your reference [1] covers
why this is the case quite nicely (and is essentially the argument for
"understandable" in my claim above).
> 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.
> We don't need to do this. We can keep a concurrent programming model and get
> the execution efficiency of an event driven model. This is what GHC's I/O
> manager achieves. On top of that we also get parallelism for free. Another
> way to look at it is that GHC provides the scheduler (using a thread for the
> event loop and a separate worker pool) that you end up writing manually in
> event driven frameworks.
So my question is - can I still get the robustness/scalability
features I get from the unix process model using haskell? In
particular, it seems like ghc starts threads I don't ask it to, and
using both threads & forks for parallelism causes even more headaches
than concurrency (at least on unix & unix-like systems), so just
replicating the process model won't work well. Do any of the haskell
parallel processing tools work across multiple systems?
thanks,
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
> 1. http://ghcmutterings.wordpress.com/2009/10/06/parallelism-concurrency/
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
