On Jun 23, 7:27pm, jo...@bec.de (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-92a675cf6...@gmx.com>, | > Kamil Rytarowski <n...@gmx.com> 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
