On 23 Jan 2016, at 08:58, Maxim Sobolev <sobo...@sippysoft.com> wrote: > > For what it's worth, I agree with David. This looks like definite misuse of > the constant. If app X requires min size of stack of Y, it's fullish of it if > to expect our PTHREAD_STACK_MIN somehow accommodate that. It should be really > using MAX(PTHREAD_STACK_MIN, Y) to set its stack instead. Should be easy to > patch and it needs to be reported to the upstream vendor(s) instead. Don't > forget that bumping this limit, no matter how small, will get multiplied by > the number of threads running, which could be in many thousands
After talking to Ed, I’m not sure I was correct in my initial assessment. The code in pthread’s thread exit routine is calling the unwinder, and that’s what’s exhausting the stack space. This means that a thread function that just does return 0 will run out of stack space. That said, existing values of PTHREAD_STACK_MIN are part of the ABI and if we’re going to bump it then we need to make sure that we do something clever with existing binaries to ensure that, when they ask for 2KB of stack, we give them more (which can be problematic if they’re allocating their own stack). I’d much prefer a solution where we don’t expose the HP unwind interfaces from libeh (it’s fine to do so from a separate libunwind) and we don’t allocate that much space in the unwinder. David _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
