In .NET 1.x if you wanted to modify the stack size of a thread you created you would have to go through some pretty nasty code .. Here is a hint :)
static extern int CreateThread (ref SECURITY_ATTRIBUTES lpThreadAttributes,
int dwStackSize, ref int lpStartAddress, ref object lpParameter,
int dwCreationFlags, ref int lpThreadId)
In 2.0 a new overload has been added to the Thread class to support alterring your stack size directly through managed code http://msdn2.microsoft.com/en-US/library/5cykbwz4.aspx. There are a few interesting things about the documentation listed.
Unmentioned in the documentation is the fact that this method will only work in Windows XP or 2003. If you are in <= 2000 you will have to use another mechanism in order to change the stack size for your thread. Chris Brumme discusses it here http://blogs.msdn.com/cbrumme/archive/2003/04/15/51351.aspx. Basically what you have to do is use a tool included with visual studio called “editbin.exe” loacted in your visual studio\bin directory. It has a /stack option which will alter your .exe to change this option for all threads in your application.
The size being “optimal“ is another questionable point .. according to SQLServer documentation http://support.microsoft.com/kb/q160683/
Keep in mind that the amount of thread stack space will vary from application to application. If you specify a stack size that is too low for your application, SQL Server will report stack overflow errors. Unfortunately, there is no easy way to estimate the amount of stack space necessary. Therefore, it is recommended that the stack space not be set below 16K. Testing has shown that this amount should be adequate for most applications.
Another odd point about the documentation is that it tells you to not use the overload.
Avoid using this constructor overload. The default stack size used by the Thread(ThreadStart) constructor overload is the recommended stack size for threads. If a thread has memory problems, the most likely cause is programming error, such as infinite recursion.
I am not sure whether this is “Mort” documentation or if there is a further reason, but I am happy to guess. The “Einstein” documentation included with the Windows API says the following
It is best to choose as small a stack size as possible and commit the stack that is needed for the thread or fiber to run reliably. Every page that is reserved for the stack cannot be used for any other purpose.
This only thing that I can think of that might nullify this would be the cardinality of managed threads to OS threads. An OS thread with a very small stack size is much less likely to be reused than a thread with a standardized stack size.
I should probably add here that I am talking about a fringe condition, in general you should not be doing this type of thing, you should be using the thread pool, but there are some circumstances when it is better not to.
What to do?