Serhiy Storchaka added the comment: Options like -fno-stack-limit and -fsplit-stack can help to avoid a crash, but they are compiler-specific and we should test how they affect the performance and memory consumption.
How can we test that the available stack is too small? This is not a part of the language, we need to use some compiler-specific tricks. If add such check, it should be added not in the c-eval loop (or not only in the c-eval loop), but for every call of tp_iternext. Recursive call can avoid the c-eval loop. Maybe add the check in PyIter_Next() and always use PyIter_Next() instead of direct calls of tp_iternext. If the check for the stack size is not cheap we can just count the deep of the recursion and check the exact stack size every say 50 levels. And this is a good opportunity to check for KeyboardInterrupt . In any case it would be useful to add a user specified limit on the deep of the recursion similar to sys.getrecursionlimit(). Even if the stack grows unlimitedly we don't want to fall in the swapping on unexpected deep recursion. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30297> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
