On Thu, 13 Oct 2005 10:23:11 -0400, Andrew Piskorski <[EMAIL PROTECTED]> wrote:
>On Fri, Oct 07, 2005 at 11:48:33AM +0100, Stuart Children wrote: >> Subject: Re: [AOLSERVER] Optimal thread stacksize? > >> I had a fun couple of days with this just before your post. AOLserver >> was crashing... some playing with gdb and I eventually realised what was >> going on and found the config option to increase thread stack size. This > >That reminds me: Just why must AOLserver set ANY fixed stack size? Is >this required by AOLserver, by Tcl, by some interaction between them, >or what? > >I've been told that Linux (at least) is able to automatically and >transparently grow and shrink each thread's C stack, but I'm not sure >if that's true. I think it might be related to mmap(), NPTL, and/or >glibc's FLOATING_STACKS, but I haven't been able to find any >definitive info on how or even whether Linux can auto-size thread >stacks. > >Can anyone provide more info on either auto-sizing stacks in general, >on Linux, or specifically with Tcl and AOLserver? > To the best of my understanding, the idea is that all your threads live in the same memory space - e.g. (numbers not to scale) thread 1 has a stack in 1000-2000, thread 2 has a stack in 2000-3000, etc. The only way I can imagine doing 'auto-sizing' stacks is by using the VM subsystems. So you'd have thread one have a stack in 1000000-2000000, thread two have stack in 2000001-3000000, etc. Except, you'd have the VM system only have pages allocated in the first bits of those stacks. If you try to grow the stack beyond where there are pages, you have a page fault, and you try to allocate memory or do whatever you have to do. The end result is you have a 'large' apparent thread stack size, without wasting buttloads of memory. Now a couple of issues with this implementation - on a 32-bit system, you only have 4 gigs of memory space to share out. Probably less, since the OS takes some, and may not give you the full 2^32. Your aolserver also needs memory for caches, and various other things. So allocating huge swaths (is that a word?) of Virtual Memory space for thread stack safety starts to become wasteful of resources, possibly? These are all envelope calculations I'm doing, so feel free to correct me, anyone. On a 64-bit system, I think you can pretty much go nuts, and allocate hugungous chunks of VM space to thread stacks. So that's the theory. I don't know how Tcl does its threads, #1, and I don't know enough about NTPL or any of the other threading models as they are actually implemented to know if these options are even available. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
