I've found it useful to use the testing of the program to also force it to get into what I think is a worst case and then printing the stack size (doing this is simple by printing argument addresses).
hth On Wed, May 19, 2010 at 11:55 AM, Federico G. Benavento <[email protected]> wrote: > also if you're using bio(8) notice that a biobuf is >8kb > > On Wed, May 19, 2010 at 6:20 AM, Sape Mullender > <[email protected]> wrote: >>> A while ago, while working on btfs, I stumbled upon some sort of >>> overflow (http://9fans.net/archive/2009/07/77) which was in fact due >>> to the thread STACK being too small (and hence if I understood >>> correctly things would get written out of it, in the heap). >>> To be on the safe side, I have it set to 16384 now, but as I think I'm >>> getting near something usable with btfs, I'd like to go back to a more >>> fitting value. I think it's pretty important to have it as low as >>> possible since the number of threads/coroutines will grow linearly >>> with the number of peers connected (to be honest, I don't even know if >>> that can even scale in terms of memory use). >>> >>> So the question is, how can I evualuate what's the minimal value I can >>> set that to without getting into trouble again? Is there anything >>> smarter than just trial and error? >> >> There's no good way, really. One thing you might do is change the thread >> library to initialize the stack to some pattern (zeroing it will probably >> do, but you can let your phantasy go wild here). You can then, when your >> code has been running for a while, use acid -lthread and a bit of scripting >> to scan your stacks for the higest point where the pattern is disturbed. >> >> >> As a general rule in threaded programs, avoid declaring local arrays >> or large structs. Instead, malloc them and free them when you're done. >> A file server, as an example, should never allocate an 8K message >> buffer on the stack. If you can manage to obey the rule of not having >> arrays on the stack (as local variables), you can usually comfortably >> make use of 4K or 8K stacks. >> >> Sape >> >> > > > > -- > Federico G. Benavento > >
