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

[Manlio Perillo]

Brandon S. Allbery KF8NH ha scritto:
> On Sep 18, 2008, at 15:10 , Manlio Perillo wrote:
>>> Allocation areas are per-CPU, not per-thread.  A Concurrent Haskell 
>>> thread consists of a TSO (thread state object, currently 11 machine 
>>> words), and a stack, which we currently start with 1KB and grow on 
>>> demand.
>>
>> How is this implemented?
>>
>> I have seen some coroutine implementations in C, using functions from 
>> ucontext.h (or direct asm code), but all have the problem that the 
>> allocated stack is fixed.
> 
> 
> That's because it's much easier to use a fixed stack.
> 
> There are two ways to handle a growable stack; both start with 
> allocating each stack in a separate part of the address space with room 
> to grow it downward.  The simpler way uses stack probes on function 
> entry to detect impending stack overflow.  The harder (and less 
> portable) one involves trapping page faults ("segmentation violation" on 
> POSIX), enlarging the stack, and restarting the instruction that caused 
> the trap; this requires fairly detailed knowledge of the CPU and the way 
> signals or page faults are handled by the OS.  (There's also a hybrid 
> which many POSIXish systems use, trapping the page fault specifically 
> when running the stack probe; the probe is designed to be safe to either 
> restart or ignore, so it can be handled more portably.)
> 

What implementation is used in GHC?

Is this more easy to implement with a pure functional language like 
Haskell, or the same implementation can be used with a procedural 
language like C?



Thanks   Manlio