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