On 11 Dec 2012, at 16:54, Chris Muller <asqueaker@gmail.com> wrote:
I don't understand how setting a fixed-size stack could ever be useful. No one would risk blowing up a production app only because they guessed wrong about the stackDepthLimit, so for production it would always be set to 0.
I kind of disagree: any system has limits, and most server software is set up to enforce limits earlier (maximum connections, file descriptors per process, â¦) and deal as gracefully as possible with them, to protect itself from external abuse or internal errors. Yes this might involve some guessing, so what. I would rather be able to deal with an infinite recursion and return an internal server error, than have the whole server crash.
So that leaves the development use-case. During development the system is already under heavy scrutiny, the real requirement is just the ability to _get back control_ when the system doesn't seem to be doing anything so that infinite recursions can be debugged. So if simply Command+. interrupt could be made to just work then there's no need to fiddle with the "guess the stack-limit" game.
With a reasonable stack or low memory limit, you won't even have to press cmd-. when something goes wrong ;-) But of course, cmd-. should just work.
I like Eliots idea of paying attention to how long the LowSpaceSemaphore fires, except not trying to analyze the stack. Instead, check how much space was _freed_ by the handlers of low-space (#freeSomeSpace I think) and, if it is Zero or very low, THEN open a debugger.
On Tue, Dec 11, 2012 at 8:00 AM, Igor Stasenko <siguctua@gmail.com> wrote:
i would be happy to have something, which can be expressed as following 'unit test':
Smalltalk vm setStackDepthLimit: 100.
self should: [ self recurseTimes: 101 ] throw: Exception.
Smalltalk vm setStackDepthLimit: 0. "no limit"
self shouldNot: [ self recurseTimes: 101 ] throw: Exception.
-- Best regards, Igor Stasenko.