On Thursday, 14 August 2014 at 07:46:29 UTC, Carl Sturtivant
wrote:
The default size of the runtime stack for a Fiber is 4*PAGESIZE
which is very small, and a quick test shows that a Fiber
suffers a stack overflow that doesn't lead to a clean
termination when this limit is exceeded.
This makes it difficult to simulate deterministic alternation
where the stack size needed is unpredictable because complex
deterministic computations are going on inside Fibers.
In contrast, the Go programming language's goroutines can
extend their stacks as needed at runtime, and so can be used to
simulate deterministic alternation without this limitation, and
yet be initially executed with each having only a small stack
size.
There seems to be a claim that all that's needed to add
D-routines (goroutines for D) is a scheduler and a Channel
type, on top of Fiber.
http://forum.dlang.org/thread/lphnen$1ml7$1...@digitalmars.com
See the initial post, point 7., as well as supporting remarks
in later replies.
Am I missing something? Is there a clean and simple way to get
Fiber to no longer suffer a stack overflow when implementing
D-routines?
Segmented stacks come with a cost. Rust abandoned them for
reasons you can read about here:
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html
I believe Go has taken steps to help mitigate stack thrashing but
I don't know if they have been successful yet.
