This is the mail archive of the
mailing list for the glibc project.
What can a thread do with PTHREAD_STACK_MIN?
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Wed, 20 Dec 2017 08:58:12 -0800
- Subject: What can a thread do with PTHREAD_STACK_MIN?
- Authentication-results: sourceware.org; auth=none
I see that both of you have been looking at pthread issues involving
stack, guards, and TLS, and their relative relations to stack sizes
in the APIs.
I would like to get consensus on what a thread can do with PTHREAD_STACK_MIN
amount of stack.
I propose the following:
The implementation only guarantees that a thread with PTHREAD_STACK_MIN
can be created, but such space does not take into consideration the
thread's stack requirements to execute the start routine. No additional
space, beyond that for the start routine, should be required to join the
Therefore for a thread to be both startable and joinable it must have
PTHREAD_STACK_MIN stack and the stack required for start routine as a
This is almost identical to what Solaris guarantees, they only mention
that PTHREAD_STACK_MIN is the minimum memory required to *start* a thread,
but don't mention how much is required to join a thread. I think the latter
is important too.
In theory, this position makes bug 22636  invalid, since no additional
stack was allocated to support cancellation.
However, I think we can all agree that we can do a better job in QoI,
and probably get enough memory back by fixing bug 22637 , and
bug 11787 , that we can support a few more operations with
PTHREAD_STACK_MIN for old applications that expected to be able to
cancel and now can't because say xsave consumed too much of the stack.
Such applications will have increased RSS usage at startup, but will
continue to work.
Thoughts on this?