[Python-Dev] stack check on Unix: any suggestions?

Guido van Rossum guido@beopen.com
Thu, 31 Aug 2000 11:07:16 -0500


> I'm confused now: how is this counting-stack-limit different from
> the maximum recursion depth we already have?
> 
> The whole point of PyOS_StackCheck is to do an _actual_ check of
> whether there's space left for the stack so we can hopefully have an
> orderly cleanup before we hit the hard limit.
> 
> If computing it is too difficult because getrlimit isn't available
> or doesn't do what we want we should probe it, as the windows code
> does or my example code posted yesterday does. Note that the testing
> only has to be done every *first* time the stack goes past a certain
> boundary: the probing can remember the deepest currently known valid
> stack location, and everything that is shallower is okay from that
> point on (making PyOS_StackCheck a subroutine call and a compare in
> the normal case).

The point is that there's no portable way to do PyOS_CheckStack().
Not even for Unix.  So we use a double strategy:

(1) Use a user-settable recursion limit with a conservative default.
This can be done portably.  It is set low by default so that under
reasonable assumptions it will stop runaway recursion long before the
stack is actually exhausted.  Note that Emacs Lisp has this feature
and uses a default of 500.  I would set it to 1000 in Python.  The
occasional user who is fond of deep recursion can set it higher and
tweak his ulimit -s to provide the actual stack space if necessary.

(2) Where implementable, use actual stack probing with
PyOS_CheckStack().  This provides an additional safeguard for e.g. (1)
extensions allocating lots of C stack space during recursion; (2)
users who set the recursion limit too high; (3) long-running server
processes.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)