This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What can a thread do with PTHREAD_STACK_MIN?
- From: DJ Delorie <dj at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: fweimer at redhat dot com, szabolcs dot nagy at arm dot com, libc-alpha at sourceware dot org, hjl dot tools at gmail dot com
- Date: Thu, 21 Dec 2017 11:57:32 -0500
- Subject: Re: What can a thread do with PTHREAD_STACK_MIN?
- Authentication-results: sourceware.org; auth=none
"Carlos O'Donell" <carlos@redhat.com> writes:
> I would like to get consensus on what a thread can do with
> PTHREAD_STACK_MIN amount of stack.
As a programmer, if I read "this is the minimum stack size" I assume
they included all their own overhead for normal "minimum user cases".
I.e. a thread that's created, does some processing that doesn't use
stack, ends, and is joined.
The programmer can't predict what glibc will need for its own overhead,
so specifying a minimum any less than needed for the above is pointless.
I don't know if this needs to include cancellation; I don't think I've
ever cancelled a thread in my entire programming career so I wouldn't
consider this "minimal". However, I (as a programmer) also wouldn't
expect a cancellation initiated by another thread to impact the stack
usage of the cancelled thread, although in hindsight if signal handlers
are involved...