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