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

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

2012/2/6 Carlos O'Donell <carlos@systemhalted.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.

Don't you read one above line?

man pthread_getattr_np(3) says
       The  pthread_getattr_np()  function initializes the thread
attributes object referred to by attr so that it contains actual
attribute values describing the running thread thread.

That's an application assumption.


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

Of course, this doesn't explain platform specific extention at all.