<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 28, 2018 at 7:51 AM Ronald Oussoren via Python-Dev <<a href="mailto:python-dev@python.org">python-dev@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I’m looking at PyOS_CheckStack because this feature might be useful on macOS (and when I created bpo-33955 for this someone ran with it and created a patch).<br>
<br>
Does anyone remember why the interpreter raises MemoryError and not RecursionError when PyOS_CheckStack detects that we’re about to run out of stack space? <br></blockquote><div><br></div><div>Running out of C stack makes more sense to me as a MemoryError, you don't know that recursion was the primary cause and the fundamental problem is that you are (about to) run out of a finite memory resource.</div><div><br></div><div>All you know is that at least one C frame on the C call stack may have required a lot of local stack space.  Just as likely as there being tons of regular sized frames.</div><div><br></div><div>RecursionError is only raised when CPython's arbitrary Python recursion depth limit is reached.  It is not raised for memory reasons.</div><div><br></div><div>In small thread stack space environments (64k, etc) I tended to find problematic code to be C code with local arrays that consumed several kilobytes each rather than actual recursion.  Python 2's own import system was notorious for that so if your server is calling service handlers in threads with a small stack and some of those are doing new imports at handler time rather than having done all imports before serving began: boom. stack overflow.</div><div><br></div><div>-gps</div></div></div>