Re: PTHREAD_STACK_MIN support

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jun 23,  7:27pm, joerg%bec.de@localhost (Joerg Sonnenberger) wrote:
-- Subject: Re: PTHREAD_STACK_MIN support

| On Thu, Jun 23, 2016 at 03:29:02PM +0000, Christos Zoulas wrote:
| > In article <f0ff615a-91e1-db16-46e1-92a675cf6231%gmx.com@localhost>,
| > Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
| > >On 08.06.2016 09:09, Martin Husemann wrote:
| > >> Maybe a minor nit:
| > >> 
| > >>         case _SC_THREAD_STACK_MIN: 
| > >> -               return _getpagesize();
| > >> +               return PTHREAD_STACK_MIN;
| > >> 
| > >> 
| > >> I would make that the max() of the two values, and also do the same for
| > >> the EINVAL test in libpthread. Machines with > 8k pages do exist.
| > >> 
| > >> Also I am still not convinced we should have this symbol, as my reading
| > >> of the standard is that our current state is perfectly fine.
| > >> 
| > >> However, MINSIGSTKSZ is wrong on those machines too, so maybe ignore for
| > >> now (or mark with XXX comments)?
| > >> 
| > >> Martin
| > >> 
| > >
| > >The point is to abstract this work to determine minimal stack size from
| > >3rd party software.
| > >
| > >Is defining it as per-port value correct?
| > 
| > What should we do with that? Is this patch ok?
| > https://github.com/ycui1984/posixtestsuite/blob/master/patches/PTHREAD/0003-add-PTHREAD_STACK_MIN.patch
| 
| I still think this is plainly wrong. We should not define
| PTHREAD_STACK_MIN and the libc+libpthread code was correct before.

Ok, I will remove it from the patch.

christos