|Title:||Allow Tcl Access to the Recursion Limit|
|Version:||$Revision: 1.11 $|
Stephen Trier <sct at po dot cwru dot edu>|
Richard Suchenwirth <richard dot suchenwirth-bauersachs at siemens dot com>
|Created:||Tuesday, 19 February 2002|
|Keywords:||Tcl_SetRecusionLimit, recursion limit|
An extension to the [interp] command, [interp recursionlimit], will permit Tcl scripts to control their own recursion limits. Until now, this limit has been changeable from a C API, but not from within Tcl.
As of Tcl 8.4a3, Tcl scripts must live with the default recursion depth of 1000 nested calls to the Tcl_Eval family of functions or resort to C code to change the limit. Nevertheless, Tcl programmers may find it useful to reduce the limit when debugging or to increase it for scripts that include deeply recursive functions. The changes proposed in this TIP will make this possible in pure Tcl code.
Add subcommands to [interp] and to the slave interpreter object command with the following syntax:
interp recursionlimit path ?newlimit?
slave recursionlimit ?newlimit?
The parameter newlimit must be a positive integer. When it is present, the limit is changed to newlimit and the command returns the new recursion limit. If the newlimit parameter is absent, the command returns the current recursion limit.
No maximum value is enforced. It is the programmer's responsibility to ensure the recursion limit will not overflow the process stack.
A safe interpreter is not allowed to change the recursion limit for itself nor for any other interpreter. Attempting to do so will generate an error. Safe interpreters are allowed to query recursion limits.
If an interpreter changes its own recursion limit to a value lower than the current Tcl_Eval nesting level, the limit will be changed, then an error message appropriate to this particular situation will be issued by the recursionlimit command. (Error text: "falling back due to new recursion limit")
If an interpreter changes a sub-interpreter's recursion limit to less than the sub-interpreter's current Tcl_Eval nesting level, no immediate error is issued. The sub-interpreter will throw a "too many nested calls to Tcl_Eval (infinite loop?)" error if its nesting is still deeper than its recursion limit when next a command is executed in its context.
Remove the now-unnecessary testsetrecursionlimit command.
Add documentation for the new subcommands, including a warning about stack overflow, much like the warning in the documentation for Tcl_SetRecursionLimit().
Add tests for the new subcommands.
Discussion of this TIP took place in the following threads:
Using a command or variable ::tcl::recursionLimit to manipulate the limit was initially considered, but Miguel Sofer suggested making the function a subcommand of [interp] because the recursion limit is logically an attribute of each interpreter. Miguel also pointed out that implementing TclpCheckStackSpace() for Unix would mitigate the dangers of setting the recursion limit too high.
comp.lang.tcl saw some discussion of whether it would be appropriate to have a way to completely remove the recursion limit. The consensus was to not add such a feature.
The initial version of this TIP did not provide for a diagnostic error message for the case where the nesting is already deeper than the new recursion level. Ken Fitch, Don Porter, Miguel Sofer, and Donal Fellows discussed whether this was important. This version of the TIP uses Donal Fellows's suggestion of changing the recursion limit as requested, but providing a meaningful error message if the nesting is too deep for the new limit.
Donal Fellows suggested that slave interpreters should inherit their recursion limit from their parent. As it turns out, this behavior was already present but was not documented. The reference implementation documents it.
An implementation of this TIP, with tests and documentation, is patch number 522849 on SourceForge.
This document is in the public domain.
[Index] [History] [HTML Format] [Source Format] [LaTeX Format] [Text Format] [XML Format] [*roff Format (experimental)] [RTF Format (experimental)]TIP AutoGenerator - written by Donal K. Fellows