Date: Fri, 12 Jul 2002 14:45:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: hackers@freebsd.org Subject: Re: Large variables on stack Message-ID: <3D2F4DE4.932D4995@mindspring.com> References: <20020712194809.A62768@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Yar Tikhiy wrote: > As I see, there are many spots in the FreeBSD userland sources where > multi-kilobyte automatic variables (e.g., string buffers) are used. > I've been taught that such variables would better be static or > allocated on heap. > > So the following question comes to my mind: To stay portable to a > reasonable degree, how large on-stack variables can be used? Depends on the system and the stack. Typically, if you want your code to be portable, you will use as little stack as possible: -------------- --------------------------------------------------- Space Stack size -------------- --------------------------------------------------- user 8MB (FreeBSD: 64MB) user thread 8K (or settable by user on pthread_create) user signals 40K[8K] (or settable via sigaltstack) kernel 8K (max; usable is closer to 4K) -------------- --------------------------------------------------- Note that this assumes none of the stack is used elsewhere; in the kernel example, ther is slightly over 3K used, on average, by the time you get to run. Another consideration is that stack is often used as a means of creating context local storage -- whether this is thread local, or session-local-in-a-finite-state-automaton, doesn't really matter. The correct approach for handling a small stack ceiling is to use allocated memory instead of stack for large amounts of data. If the data itself is small, but there is a lot of it, it's best to put it in a struct, and the allocate an instance of the struct, using only enough memory for the struct pointer itself, from the stack. OpenSSL is a good example of how not to write code. Be aware that at some point in the future, even if you are writing code to run in a normal user program today, that you might want to have multiple instances of the program, and that at that point, you might want to use threads -- and you stack ceiling goes way down at that point. Even if you specify the stack size itself to the threads system, by explicitly allocating per threads stacks, and doing all the necessary threads management, you are still limited. Someone is going to have to maintain this code without your knowledge that you selected the stack size to come within 3 bytes of exhaustion in a particular code path (and any changes there that add a single int variable will cause the programs head to explode). In addition, while it's not very advisable, there are a lot of people who think shoving code into the kernel will "magically" make it run faster, even if there is not really very much in the way of protection domain crossing involved. For those people, moving from an environment where you can, for all intents and purposes, ignore stack size, to one where "you've got just over 4K, live with it" is practically impossible. My gut feeling is: if you are asking this question, then you are trying to justify doing something that you know is bad, but want to do anyway because it would be easier than doing it right. My answer to that is: trust your instincts, even if it means more work. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2F4DE4.932D4995>