core.thread.Fiber --- runtime stack overflow unlike goroutines

Dicebot via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Aug 22 09:08:15 PDT 2014


On Friday, 15 August 2014 at 15:50:30 UTC, Dicebot wrote:
> On Friday, 15 August 2014 at 15:40:35 UTC, Sean Kelly wrote:
>> On Friday, 15 August 2014 at 15:25:23 UTC, Dicebot wrote:
>>>
>>> No, I was referring to the proposal to supply bigger stack 
>>> size to Fiber constructor - AFAIR it currently does allocate 
>>> that memory eagerly (and does not use any OS CoW tools), 
>>> doesn't it?
>>
>> I thought it did, but apparently the behavior of VirtualAlloc 
>> and mmap (which Fiber uses to allocate the stack) simply 
>> reserves the range and then commits it lazily, even though 
>> what you've told it to do is allocate the memory.  This is 
>> really great news since it means that no code changes will be 
>> required to do the thing I wanted to do anyway.
>
> Guess that means some experimenting this weekend for me too :)

Looks like it indeed just magically works. I have used this 
simple program:

import core.thread;

void foo()
{
//  int[10240] array;
     Fiber.yield();
     for (;;) {}
}

void main()
{
     foreach (_ ; 0 .. 10_000)
     {
         //auto fiber = new Fiber(&foo);
         auto fiber = new Fiber(&foo, 100_000);
         fiber.call();
     }
}

And checked peak memory profile via `time --format="%M"`. Fiber 
constructor argument size did not change memory consumption at 
all, only changing size of fiber stack variables did.


More information about the Digitalmars-d-learn mailing list