Question about our default pthread stack size

[Alexander Nedotsukov]

Daniel Eischen wrote:

>On Mon, 22 Nov 2004, Alexander Nedotsukov wrote:
>
>  
>
>>Daniel Eischen wrote:
>>
>>    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 :-)
>>    
>>
>
>You're missing my point.  There is a perfectly good POSIX standard for
>setting thread stack size -- you don't even need to allocate it yourself.
>Using pthread_attr_setstacksize() is more portable than relying on
>the OS to guess at what an application's stack size requirements are.
>  
>
Daniel, this is what I said in my very first letter under the topic. I 
know how portable code must look like. API is  good and complete. Let's 
clear thing up yet more to understand each other completely. My points are:

- there is an omision in standard (or better to say something that is 
hard to standardize)
  Therefore there is a term like default stack size which can be 
understood as the amount enough for regular code. Otherwise it will be 
more logical to make thread stack size argument mandatory for 
pthread_create().
- main stream follows the stack usage rules I described above and chosen 
1MB/2MB for their default stacks size.
- we have limit which most likely triggers SIGSEGV.

At this point I believe we both agreed that there is a sence to break 
64K limit. Right?
Than the only open question how much we will grow it up. My point is 
that if we going to use lower numbers we must give a good reason for 
that. Some technical issues I guess like performance penalty whatever...
My main question I'd like to hear the answer is:

If we can not prove being as safe as main stream and do not win anything 
in technical aspect than why we must do extra work?

I can understand if there is some true technical issue which prevents us 
form be inline with others. But I do not if we just pushing people to 
use APIs speculating on standard omisions.

>We may increase it to 1MB now, but what happens when that is not enough?
>And you _know_ one day, perhaps sooner than you realize, that it won't
>be enough.
>  
>
This will be a problem for everyone not just for FreeBSD users. Perhaps 
that day will be a good time to prove Solaris/Linux/Windows OS engineers 
who was right. But now I think we lost the race.

All the best,
Alexander.