tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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.

Joerg


Home | Main Index | Thread Index | Old Index