Are Fibers just broken in D?

[bauss]

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:
>> 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.

And in the end of the day it makes no sense to have that many 
fibers as they would probably perform terrible.