[thoughtpolice]

The runtime is SMP-capable and lightweight threads are preemptable, multiplexed on top of epoll (or kqueue) based event loops. So it's a preemptive N:M model. Haskell threads basically try to behave like OS threads as much as possible (with semantics that look like they're blocking) but they have a lot better cost model overall, so you don't need to do manual callback-based programming. It's pretty nice.

There are really dozens of concurrency abstractions you can choose from, and yes, CSP-style programming is an option, available as a library: http://hackage.haskell.org/package/chp - and common abstractions like MVars (which are essentially simple, concurrent 1-place queues) can get you a long way even without that.

There are other libraries for more specific needs; like graph/dataflow based parallelism, array parallelism, GPU-based programming, DSLs for image processing, etc etc.

All that said I'm very happy and hopeful to see OCaml 4.03 adopt multicore support. OCaml has an excellent, robust and lightweight toolchain and implementation, and is very straight-forward and powerful out of the box. It's not my personal cup of tea, but we'd be worse off if they weren't here.

[istvan__]

Thank you for the detailed response.

OCaml is not my cup of tea either, but it is really interesting to learn it. If you have any ML like experience than I guess it is less interesting though. The toolchain is great this was one reason I decided to try it out.