setrecursionlimit

[Chris Kaynor]

On Wed, May 18, 2016 at 10:15 AM, Steven D'Aprano <steve at pearwood.info>
wrote:

> I don't really understand why the system can't track the current top of the
> stack and bottom of the heap, and if they're going to collide, halt the
> process. That would still be kinda awful, in a sudden "your application
> just died" kind of way, but it would be better than "your computer is now
> owned by some hacker in Hong Kong, who is now renting it by the hour to
> some spammer in Texas".
>

Most modern OSs will track it, and kill the app (hence the exception/crash
that occurs), rather than allow access outside the memory.

What generally happens is that, when a thread is created (including the
main thread during startup), the OS will allocate enough pages to hold the
requested stack, plus one as a buffer. Most of these are virtual pages,
with no backing memory allocated (either in RAM or the page file). When the
next page is first requested, the OS will actually allocate the RAM needed
for that page of the stack. If the final guard page is hit, the OS will
throw an exception, which generally kills the app. This means there is a
overhead when a previously unused stack page is hit, however, as this
generally does not happen often, it is generally acceptable.

I cannot quickly find the reference material I learned this from, and
naturally it will vary based on the OS, however this is pretty standard for
general purpose, modern OSes.

Chris