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

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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: Dealing with multiple page sizes in NPTL


Steve, Roland,


Steve Munroe wrote:
> Roland McGrath <roland@redhat.com> wrote on 10/16/2005 07:54:15 AM:
> 
> > A different question is PTHREAD_STACK_MIN.  When an application 
> > allocates
> > its own thread stack, then 16384 may be perfectly adequate regardless 
of
> > the page size.  One can make the case that an application writer might 

> > want
> > to minimize memory consumption at the expense of foregoing guard 
pages. 
> > A
> > clever application writer might even do his own allocation with guard 
> > pages
> > below but use the rest of the page above the stack for other purposes, 

> > when
> > the page size is much larger than the actual stack requirements.
> > 
> > However, the standard would seem to indicate that an application can 
use
> > pthread_attr_setstacksize without pthread_attr_setstackaddr (and 
rather
> > than pthread_attr_setstack), passing PTHREAD_STACK_MIN, and expect to
> > create a thread with a guard page.  For that to work, 
PTHREAD_STACK_MIN 
> > has
> > to be at least a page over the minimum usable stack (for the guard 
> > page).
> > The standard explicitly mentions that the effective guardsize may be
> > page-rounded.  I don't think the standard clearly says whether the
> > guardsize is included in the stacksize, but that's what we do.  That 
> > being
> > the case, PTHREAD_STACK_MIN not being more than a page just makes no 
> > sense.
> > There is an argument to be made that when pthread_attr_setstacksize
> > succeeds without complaint (because the PTHREAD_STACK_MIN minimum was 
> > met),
> > then pthread_create should not then fail because that size is too 
small.
> > The only way to oblige that is to round up the requested size when
> > allocating, to big enough for the guard page and the minimum usable 
> > stack.
> > But then that runs afoul of the specification that it's "the size of 
the
> > thread stack", meaning that the application might expect it to be 
exact
> > (with reliable overflow behavior).

The Standard is unclear on whether PTHREAD_STACK_MIN includes the 
guard page, or if the guard page is considered to be allocated in addition 
to
the stack size requested by the application. The Joint Working Group is
happy with this being unspecified (meaning it can be implemented either
way and be conforming); I brought the question up, Ulrich replied with how
glibc implements it, and there are no objections at present even from
those who implement it the other way (as an addition to requested size).


-------------------

bmark@us.ibm.com


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