Advice requested for fixing issue 17914

[Nemanja Boric]

On Wednesday, 25 October 2017 at 15:22:18 UTC, Nemanja Boric 
wrote:
> On Wednesday, 25 October 2017 at 15:12:27 UTC, Nemanja Boric 
> wrote:
>> 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:
>>>> [...]
>>>
>>> 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.
>
> I'm not sure that would allow us to mprotect the page guards, 
> though.

I think the easiest way to proceed from here is to default the 
stack protection page to 0, so we avoid this regression. Once 
that's in, we can think about different allocation strategy for 
the fiber's stacks or throwing the exceptions on too many fibers 
(too bad mmap doesn't return error code, but you get SIGABRT 
instead :( )

What do you think?