Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Chris Kaynor Newsgroups: comp.lang.python Subject: Re: setrecursionlimit Date: Wed, 18 May 2016 10:47:05 -0700 Lines: 29 Message-ID: References: <573c941f$0$22141$c3e8da3$5496439d@news.astraweb.com> <573ca324$0$1604$c3e8da3$5496439d@news.astraweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: news.uni-berlin.de 4rCilb4KIHjkTmoNqBqWFA3lTfj1yqcO/p3/fQ0/Un8Q== Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'memory.': 0.05; 'subject:skip:s 10': 0.05; 'stack.': 0.07; 'cc:addr:python-list': 0.09; 'buffer.': 0.09; 'exception,': 0.09; 'naturally': 0.09; 'stack,': 0.09; 'throw': 0.09; 'thread': 0.10; 'stack': 0.13; 'wed,': 0.15; '"your': 0.16; '"your': 0.16; '(either': 0.16; '10:15': 0.16; '2016': 0.16; 'file).': 0.16; 'heap,': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'to:addr:pearwood.info': 0.16; "to:name:steven d'aprano": 0.16; 'wrote:': 0.16; 'app': 0.16; 'memory': 0.17; 'cc:2**0': 0.20; 'cc:addr:python.org': 0.20; 'os,': 0.22; 'am,': 0.23; 'previously': 0.24; 'header:In-Reply-To:1': 0.24; 'chris': 0.26; 'pages,': 0.27; 'message-id:@mail.gmail.com': 0.27; 'allocated': 0.27; 'hacker': 0.29; '(including': 0.30; "can't": 0.32; 'generally': 0.32; "d'aprano": 0.33; 'ram': 0.33; 'steven': 0.33; 'quickly': 0.34; 'that,': 0.34; 'received:google.com': 0.35; 'next': 0.35; 'but': 0.36; 'needed': 0.36; 'there': 0.36; 'created': 0.36; 'received:209.85': 0.36; 'subject:: ': 0.37; 'really': 0.37; 'virtual': 0.38; 'received:209': 0.38; 'received:209.85.220': 0.38; 'means': 0.39; 'why': 0.39; 'material': 0.39; 'does': 0.39; 'application': 0.39; 'enough': 0.39; 'rather': 0.39; 'still': 0.40; 'some': 0.40; "they're": 0.66; 'hour': 0.69; 'oss': 0.84; 'spammer': 0.84; 'hong': 0.96 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zindagigames-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f/0vMWLeUUa8wN54SqHBWdFjKUDrS4AAKaImvtojXEM=; b=hWqEUtBveifoROFPcho/dGaV2eJmOJL6W4mMEL36COC606h5TJz/vEcic6SXkJ121Q xAuAiln7H9GF6FX6drPdebbM/kwtBruYlYcRBYdzOlfqrJMlFjF4Trw7JgotjXpsUfg1 9igNOhRfMKl30ExpZ2iQSiDTu8WEJZue/TIlJrWUMz2FPVzsRviXjhIIhimZ3NazlKCv FLZRx7May+6j0XZnIycF2vaBioghaX+LVDtfuFjpr4v/BdZQH1PMby8UXQcPGsLlVh/y tvVmDaH/fXimtIidgk3wauPjhtR/Pe794mLIG5L6joawSnQKziO8fQ/YpC1Eu5nOHCFP 6dSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f/0vMWLeUUa8wN54SqHBWdFjKUDrS4AAKaImvtojXEM=; b=Zd1oSJuECtgD5cAV4NujMOgYvedGErPYjwKI/ILKfuxpvrCDDkQOZMoa3DshAGPMrj E9+eTdAbcqw5SMCT9SohlZSUk60TqnZcWPrEnNM/CDL34TccsBiiptBZ5c0W1EA1oCQx DSHsb6ceX6pV2LO5M7xU5G8hATHkpjjLVeuRToH9F4+5MoqSYGuwareSi/NaxnlrCOCA 4qXkWx8w9nCh6VzNTQ1NRYRqI0sIn7beKO3/k5a7sXe6ts1ohK9T/+jixr5qDv/ls2em NAubZd6LMx3az3eQK+wJrv1jhGX+UzgISJHKp4/cGGW2I5f27cOAhmjwjh1qzBu8qyvT F0RQ== X-Gm-Message-State: AOPr4FVtryDwppoVAsTNf9fdRBvcAq5e1TzptQxbP2eA3I69jpubYtiqgBM5Kkdhr0XTpHG/Zvt9oGTpGslKug== X-Received: by 10.55.217.89 with SMTP id u86mr9102237qki.167.1463593644469; Wed, 18 May 2016 10:47:24 -0700 (PDT) In-Reply-To: <573ca324$0$1604$c3e8da3$5496439d@news.astraweb.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <573c941f$0$22141$c3e8da3$5496439d@news.astraweb.com> <573ca324$0$1604$c3e8da3$5496439d@news.astraweb.com> Xref: csiph.com comp.lang.python:108781 On Wed, May 18, 2016 at 10:15 AM, Steven D'Aprano 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