Are Fibers just broken in D?

[Radu]

On Tuesday, 24 April 2018 at 13:36:48 UTC, Steven Schveighoffer 
wrote:
> On 4/24/18 5:11 AM, bauss wrote:
>> On Tuesday, 24 April 2018 at 07:58:01 UTC, Radu wrote:
>>> On Tuesday, 24 April 2018 at 00:46:39 UTC, Byron Heads wrote:
>>>> [...]
>>>
>>> This is not a fiber issue but a more memory management issue. 
>>> Your run out of address space on win32, the GC will not 
>>> always collect all those 99999 fibers that you allocate in 
>>> that loop. As an exercise replace `auto` with `scope` like 
>>> `scope foo = new Foo();` in that loop - you should see 
>>> different results.
>
> This shouldn't be a requirement, the 32-bit GC is generally not 
> this bad.
>

Allocating so many fibers in a loop produces an OOM error on 
win32, that's a fact! Event though it doesn't always happen you 
often get OOM errors with the program above.

Probably the cause is related to how often the collection kicks 
in in relation to the pages allocated via VirtualAlloc. But 
still, the issue OP raised is not a Fiber related issue but a 
memory management issue.

>>>
>>> The issue boils down to the call to VirtualAlloc that the 
>>> fiber constructor makes, which fails as Windows will not 
>>> allocate any more virtual pages for the process. If you 
>>> really want that many fibers you should reconsider 32 bit, 
>>> and definitely use a different allocation strategy.
>> 
>> And in the end of the day it makes no sense to have that many 
>> fibers as they would probably perform terrible.
>
> Let's not forget though, that he's executing the fiber 
> completely within the loop. It should be done and collected.
>
> This is not the case of executing 100,000 concurrent fibers, 
> but executing 100,000 *sequential* fibers. It should work just 
> fine.
>
> -Steve