This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>> 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.

pthread_getattr_np(&attr);
ptrhead_attr_getstacksize(attr);


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.

So, To add new mmap flags may be an option. but, unconditional behavior changes
don't makes sense to me.

Thanks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]