3 ms·

Thanks -- I just tried it, it came out to over 200k calls for me. It is big, yes, but, in writing robust code, you have to anticipate and handle a stack overfl

Thanks -- I just tried it, it came out to over 200k calls for me. It is big, yes, but, in writing robust code, you have to anticipate and handle a stack overflow cleanly. How do you do this?

ars 12y ago
> you have to anticipate and handle a stack overflow cleanly. How do you do this? You use sigaltstack and catch SIGSEGV. It's probably easier to handle if you hit a soft limit rather than the heap. Then you raise the limit, set a flag to make your functions unwind and reduce the limit again.
danbruc 12y ago
You just don't write a recursive program if there is the possibility that it may run out of stack space due to the provided arguments.
Gmo 12y ago
This is implementation dependent. In the JVM and the .NET VM, you can't handle it cleanly.
Chris_Newton 12y ago
It is big, yes, but, in writing robust code, you have to anticipate and handle a stack overflow cleanly. How do you do this? In principle, you have that problem with almost any language that uses the system stack to pass arguments when it makes a function call. It just happens to be easier to trigger it if you use a recursive algorithm, because it’s unlikely that you would write a program with 200,000 distinct functions each of which just called the next in a chain until something fell over. In practice, recursive algorithms are often used to walk recursive data structures and often have logarithmic complexity in the size of the data structure. Even structures that fill the memory of a supercomputer probably aren’t going to need more than a few hundred levels of recursion in that scenario, while the available stack space is probably several orders of magnitude larger. So to be blunt, unless you really are talking about something where failure really isn’t an option (safety critical systems and the like), you probably just treat this as the same kind of catastrophic failure that running out of system memory would be, and use some OS-level support to abort as gracefully as you can if the sky falls. If you really are working in a more constrained environment — safety-critical code, say, or perhaps an embedded system with relatively little memory — then it might be the case that you simply avoid the recursion altogether unless you’re using a language that guarantees tail recursion will be dealt with robustly. Some coding standards forbid the use of dynamically allocated memory for much the same reason, and you just have to use different tools to solve those problems if you’re working with such constraints.

Thanks -- I just tried it, it came out to over 200k calls for me. It is big, yes, but, in writing robust code, you have to anticipate and handle a stack overflow cleanly. How do you do this?

ars 12y ago

> you have to anticipate and handle a stack overflow cleanly. How do you do this? You use sigaltstack and catch SIGSEGV. It's probably easier to handle if you hit a soft limit rather than the heap. Then you raise the limit, set a flag to make your functions unwind and reduce the limit again.

danbruc 12y ago

You just don't write a recursive program if there is the possibility that it may run out of stack space due to the provided arguments.

Gmo 12y ago

This is implementation dependent. In the JVM and the .NET VM, you can't handle it cleanly.

Chris_Newton 12y ago

It is big, yes, but, in writing robust code, you have to anticipate and handle a stack overflow cleanly. How do you do this? In principle, you have that problem with almost any language that uses the system stack to pass arguments when it makes a function call. It just happens to be easier to trigger it if you use a recursive algorithm, because it’s unlikely that you would write a program with 200,000 distinct functions each of which just called the next in a chain until something fell over. In practice, recursive algorithms are often used to walk recursive data structures and often have logarithmic complexity in the size of the data structure. Even structures that fill the memory of a supercomputer probably aren’t going to need more than a few hundred levels of recursion in that scenario, while the available stack space is probably several orders of magnitude larger. So to be blunt, unless you really are talking about something where failure really isn’t an option (safety critical systems and the like), you probably just treat this as the same kind of catastrophic failure that running out of system memory would be, and use some OS-level support to abort as gracefully as you can if the sky falls. If you really are working in a more constrained environment — safety-critical code, say, or perhaps an embedded system with relatively little memory — then it might be the case that you simply avoid the recursion altogether unless you’re using a language that guarantees tail recursion will be dealt with robustly. Some coding standards forbid the use of dynamically allocated memory for much the same reason, and you just have to use different tools to solve those problems if you’re working with such constraints.