[Haskell-cafe] Re: Python's big challenges, Haskell's big advantages?

[Evan Laforge]

>> systems that don't use an existing user-space thread library (such as
>> Concurrent Haskell or libthread [1]) emulate user-space threads by
>> keeping a pool of processors and re-using them (e.g., IIUC Apache does
>> this).
>
> Your response seems to be yet another argument that processes are too
> expensive to be used the same way as threads.  In my mind pooling vs
> new-creation is only relevant to process vs thread in the performance
> aspects.  The fact that people use thread-pools means that they think
> that even thread-creation is too expensive.  The central aspect in my
> mind is a default share-everything, or default share-nothing.  One is
> much easier to reason about and encourages writing systems that have
> less shared-memory contention.

This is similar to the plan9 conception of processes.  You have a
generic rfork() call that takes flags that say what to share with your
parent: namespace, environment, heap, etc.  Thus the only difference
between a thread and a process is different flags to rfork().

Under the covers, I believe linux is similar, with its clone() call.

The fast context switching part seems orthogonal to me.  Why is it
that getting the OS involved for context switches kills the
performance?  Is it that the ghc RTS can switch faster because it
knows more about the code it's running (i.e. the OS obviously couldn't
switch on memory allocations like that)?  Or is jumping up to kernel
space somehow expensive by nature?  And why does the OS need so many
more K to keep track of a thread than the RTS?  I don't really know
much about either OSes or language runtimes so this is interesting to
me.