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). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4