On Wed, May 18, 2016 at 10:15 AM, Steven D'Aprano <st...@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 -- https://mail.python.org/mailman/listinfo/python-list