Advice requested for fixing issue 17914

Steven Schveighoffer schveiguy at yahoo.com
Wed Oct 25 15:32:36 UTC 2017


On 10/25/17 11:12 AM, 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:
>>> 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?
>>
> 
> 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.

Hm... the mprotect docs specifically state that calling mprotect on 
something that's not allocated via mmap is undefined. So if you use GC 
to allocate Fiber stacks, you can't mprotect it.

I think what we need is a more configurable way to allocate stacks. 
There is a tradeoff to mprotect vs. simple allocation, and it's not 
obvious to choose one over the other.

I still am baffled as to why this is now showing up. Perhaps if you are 
using mmap as an allocator (as Fiber seems to be doing), it doesn't 
count towards the limit? Maybe it's just glommed into the standard 
allocator's space?

-Steve


More information about the Digitalmars-d mailing list