freenode/#sbcl - IRC Chatlog
Search
5:08:15
White_Flame
on control stack exhaustion, it says "PROCEED WITH CAUTION". What are the cautions to take?
5:08:53
White_Flame
Does it have to do with unwinding, or potential trampling of important info after the stack, or what sorts of danger?
5:09:22
White_Flame
I would like to programmatically recover from such situations, substituting in a slower version with less stack pressure if such is hit
5:10:14
White_Flame
to my understanding, it doesn't appear that threads can be created with different stack sizes, which would be ideal
7:34:10
flip214
White_Flame: src/code/target-thread.lisp already uses pthread_attr_setstacksize, using sb-unix::pthread-min-stack ... you could either change that to (or *required-thread-stack-size sb-unix::pthread-min-stack) and override that where needed
8:02:28
White_Flame
in any case, my primary question was about the "proceed with caution" and what problems might step from the stack overflow
8:44:05
flip214
but unwinding should be possible, the debugger doesn't work much differently either, I guess
8:44:28
Krystof
the main concern is "don't blow the stack again, it might be less protected than before"
8:44:44
Krystof
I can't actually remember if we have two guard pages or not, but if we only have one, the next stack overflow probably crashes
8:44:52
flip214
As there is a "ABORT - Return to SLIME's top level." you should be able to have your own handler as well
8:45:07
White_Flame
so ideally throw away the thread and restart on a fresh one with more defensive/slower code if you're going to retry it
8:46:11
White_Flame
flip214: I intend to grab application-specific data from another thread via snooping it, then having the whole thing unwind
8:47:43
White_Flame
but even then, just letting it die and using a more cautious & recursion-tracking version of the code probably also removes the need to try to extract what caused the overflow in the dead thread anyway
9:08:40
flip214
White_Flame: for snooping you might get away with (sb-thread:interrupt-thread) - though that might be a bad idea if you just ran out of stack
10:24:17
luis
Unless you're on Windows, in which case stack overflow blows everything up on the first try. :-)
10:35:50
flip214
I'd love to have atomic GF/method updates, so that redefining a method on a busy server doesn't ever give "There is no applicable method for the generic function ... when called with arguments ..."
10:39:44
flip214
luis: well, there was an applicable method which got redefined - so if the GF dispatcher function would be changed atomically it wouldn't break