On Mon, Apr 18, 2011 at 9:13 AM, Mike Meyer <mwm@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].

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).

Now, naively mapping this (concurrent) *programming model* to an *execution model* i.e. OS threads might give us less than optimal performance. At this point what often happens (i.e. in NodeJS and other event driven web frameworks) is that the programming model is thrown out with the execution model. This results in callback-spaghetti and lack of separation of concerns [2].

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.

-- Johan

1. http://ghcmutterings.wordpress.com/2009/10/06/parallelism-concurrency/
2. http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf - This discusses the observer pattern, which is very closely related to how event driven frameworks work (i.e. using callbacks).