[Haskell-cafe] Re: Python's big challenges,
Haskell's big advantages?
manlio_perillo at libero.it
Fri Sep 19 17:14:04 EDT 2008
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
>> 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?
More information about the Haskell-Cafe