Advice requested for fixing issue 17914

[Nemanja Boric]

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.