Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #108781

Re: setrecursionlimit

From Chris Kaynor <ckaynor@zindagigames.com>
Newsgroups comp.lang.python
Subject Re: setrecursionlimit
Date 2016-05-18 10:47 -0700
Message-ID <mailman.16.1463593647.27390.python-list@python.org> (permalink)
References <573c941f$0$22141$c3e8da3$5496439d@news.astraweb.com> <d75fdf2c-fa98-4d6d-93ba-47a63c330e16@googlegroups.com> <nhi5a4$99a$1@dont-email.me> <573ca324$0$1604$c3e8da3$5496439d@news.astraweb.com> <CALvWhxuUcf_cxum-ErKMQGYwmwDhoUP0R_mMx2UDDSUOmLTLwg@mail.gmail.com>

Show all headers | View raw


On Wed, May 18, 2016 at 10:15 AM, Steven D'Aprano <steve@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

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

setrecursionlimit Steven D'Aprano <steve@pearwood.info> - 2016-05-19 02:11 +1000
  Re: setrecursionlimit Ned Batchelder <ned@nedbatchelder.com> - 2016-05-18 09:19 -0700
    Re: setrecursionlimit Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-05-18 16:29 +0000
      Re: setrecursionlimit Steven D'Aprano <steve@pearwood.info> - 2016-05-19 03:15 +1000
        Re: setrecursionlimit Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-18 11:38 -0600
        Re: setrecursionlimit Chris Kaynor <ckaynor@zindagigames.com> - 2016-05-18 10:47 -0700
          Re: setrecursionlimit breamoreboy@gmail.com - 2016-05-18 14:43 -0700
            Re: setrecursionlimit Rustom Mody <rustompmody@gmail.com> - 2016-05-18 20:19 -0700
              Re: setrecursionlimit Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-19 21:04 +1200
        Re: setrecursionlimit Christian Gollwitzer <auriocus@gmx.de> - 2016-05-18 20:11 +0200
        Re: setrecursionlimit Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-19 21:00 +1200
    Re: setrecursionlimit Chris Kaynor <ckaynor@zindagigames.com> - 2016-05-18 09:56 -0700
    Re: setrecursionlimit Nobody <nobody@nowhere.invalid> - 2016-05-19 11:28 +0100
  Re: setrecursionlimit Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-05-19 10:27 +0100

csiph-web