On Wednesday, 25 October 2017 at 14:19:14 UTC, Jonathan M Davis
wrote:
On Wednesday, October 25, 2017 09:26:26 Steven Schveighoffer
via Digitalmars-d wrote:
On 10/23/17 12:56 PM, Brian Schott wrote:
> Context: https://issues.dlang.org/show_bug.cgi?id=17914
>
> I need to get this issue resolved as soon as possible so
> that the fix makes it into the next compiler release.
> Because it involves cleanup code in a class destructor a
> design change may be necessary. Who should I contact to
> determine the best way to fix this bug?
It appears that the limitation applies to mmap calls as well,
and mmap call to allocate the stack has been in Fiber since as
far as I can tell the beginning. How has this not shown up
before?
Maybe there was a change in the OS(es) being used that affected
the limit?
- Jonathan M Davis
Yes, the stack is not immediately unmapped because it's very
common
just to reset the fiber and reuse it for handling the new
connection -
creating new fibers (and doing unmap on termination) is a problem
in the
real life (as this is as well).
At sociomantic we already had this issue:
https://github.com/sociomantic-tsunami/tangort/issues/2 Maybe
this is the way to go - I don't see a reason why every stack
should be mmaped separately.
