Question about our default pthread stack size

[Alexander Nedotsukov]

Daniel Eischen wrote:

>On Fri, 19 Nov 2004, Joe Marcus Clarke wrote:
>
>  
>
>>Daniel Eischen wrote:
>>| The thing I worry about is these piggy applications being the
>>| driving force behind our stack size.  If they really are designed
>>| to need a huge stack size, they should be the ones that change
>>| to support it, not the other way around.  Do they know their own
>>| stack space requirements or do they just ignore it because it
>>| isn't a problem so far (on Linux)?
>>
>>The bottom line is that they don't know their stack requirements, but
>>the OS is accommodating, so they never have to really find out until we
>>submit a bug to them.  However, some applications (e.g. gstreamer,
>>libgnomecups, etc.) cannot be fixed without massive architectural
>>changes.  Just to be clear, these applications _are_ overrunning the
>>default stack.
>>    
>>
>
>FYI, I don't suggest they change their stack usage, just that
>they create threads with thread attributes specifying a larger
>stack size.  If they recognize they have large stack space
>requirements, it should be easily solved without an architectural
>overhaul.  I assume your patches do exactly this; are the GNOME
>developers reluctant to incorporate your patches?
>
>I'm not going to argue very strongly against changing the
>default stack size.  I just think the onus should be on
>the larger applications to recognize that they need larger
>stacks and to explicitly set it.  There may also be other
>applications that create a lot of threads which may need
>to lower the stack size if the default were changed.
>
>  
>
I want to explain my personal opinion about blaming heavy stack usage. 
This probably explains how other userland programmers think about his 
problem:

    Heavy stack usage is not so evil like it may look like. That "pig" 
will have to allocate big memory chunk anyway and the usual options here 
are to grab phys memory page on the heap through the malloc() or do it 
on the stack. In both of the cases this memory will not be immediately 
allocated. But malloc() way will be slower and this is why multimedia 
processing code may prefer on stack allocation. Another malloc/free() 
disadvantage for C program is potential memory leakage. People may feel 
safer when they don't have to check all return paths but get automatic 
memory disposal.
One more thing about "Do they know their own stack space requirements". 
No they don't. And the whole idea here I believe was to let them don't 
care at all. I doubt very much if such research for something like 
OpenOffice will worth the efforts. So it is more practical to follow 
Bill's like "no one can beat xxx barrier". Where xxx is 1MB in our 32bit 
case :-)

So finally. If we going to keep stack limit lower than it is on other 
OSes we have to provide programmers with good arguments why the above I 
said is not correct and/or why we think our numbers are better. 
Otherwise we trouble people because of reason we don't honestly know.

Hey, and now let's do something. Do not keep this suspicious silence! ;-)

All the best,
Alexander.
ps. btw no one commented the idea of making this $limits -s tunable 
(default limit will be inherited from the main thread) thus making both 
of the worlds happy.