Are Fibers just broken in D?

[Radu]

On Tuesday, 24 April 2018 at 00:46:39 UTC, Byron Heads wrote:
> On Friday, 20 April 2018 at 20:52:17 UTC, Byron Moxie wrote:
>> On Friday, 20 April 2018 at 20:46:20 UTC, Steven Schveighoffer 
>> wrote:
>>> On 4/20/18 2:58 PM, Byron Moxie wrote:
>>>> [...]
>>>
>>> It sounds like the problems may be due to Win32 and not the 
>>> other pieces. Have you tried on a Win64 build? Even if that's 
>>> not your target, at least it can help you discover whether 
>>> that is the problem or not. The DMC runtime is the default on 
>>> Win32, and it's not especially thread-safe in all places.
>>>
>>> FWIW, I'm using vibe.d on Linux 64 bit with no problems (and 
>>> I've NEVER heard of atomicLoad and atomicStore not working on 
>>> any arch).
>>>
>>> -Steve
>>
>> I had move the data I wanted to sync with atomicLoad/Store 
>> into a shared struct and pass a pointer to this struct to the 
>> other fibers. Not sure if this was an issue with TLS messing 
>> with class object I was passing around.
>
>
>
> Fibers on Win32 have a memory leak for sure:
>
> import core.thread : Fiber;
>
> void main() {
>
>     foreach(ulong i; 0..99_999) {
>         auto foo = new Foo();
>         foo.call();
>         foo.call();
>     }
> }
>
>
> class Foo : Fiber {
>     this() {
>         super(&run);
>     }
>
>
>     void run() {
>         Fiber.yield();
>     }
> }
>
>
> Running this with -m64 on windows runs without a problem, but 
> with -m32 it failes aith a Memory Allocation failed error.

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.

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.