Re: Fixed size of thread stacks in the nptl pthread implementation

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, Feb 6, 2012 at 4:03 PM, KOSAKI Motohiro
<kosaki.motohiro@gmail.com> wrote:
>>> You might want to ask on the Austin Group Mailing list if anything
>>> would prevent a conforming POSIX implementation from having a growing
>>> stack as the default (I say default because that's the only case where
>>> the implementation has control over the creation of the stack space)?
>>
>> the pthread stack funcs that set the size say everywhere that the valid
>> specified is only the guaranteed minimum. ?that says to me that growing is
>> allowed by the implementation.
>
> Austin? This seems to doesn't make sense. Userland applications assume
> the following code return right stack size.

Yes, the Austin Group, they work on POSIX and SUS.

http://www.opengroup.org/austin/

> pthread_getattr_np(&attr);
> ptrhead_attr_getstacksize(attr);

No, pthread_attr_getstacksize returns the "thread *creation* stack
size" not the current thread stack size.

http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_attr_setstacksize.html

> Moreover, *now* some userland applications have automatic stack
> growing by using hadling SIGSEGV. It makes sense because app can
> handle app specific
> stack growing length limitation.

This is so far the *best* argument against automatically growing
stacks: the application can handle growing the stack with better
knowledge of the required semantics.

I don't know how easy it is to do this, or how portable, which is yet
another problem outside the scope of todays discussion on default
thread stack behaviour.

Cheers,
Carlos.