core.thread.Fiber --- runtime stack overflow unlike goroutines
Brad Anderson via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Thu Aug 14 12:19:40 PDT 2014
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.
More information about the Digitalmars-d-learn
mailing list