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