Re: PTHREAD_STACK_MIN support

2016-06-23 Thread Christos Zoulas
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 +, Christos Zoulas wrote: | > In article , | > Kamil Rytarowski wrote: | > >On 08.06.2016 09:09, Martin Husemann wrote: | > >&

Re: PTHREAD_STACK_MIN support

2016-06-23 Thread Joerg Sonnenberger
On Thu, Jun 23, 2016 at 03:29:02PM +, Christos Zoulas wrote: > In article , > Kamil Rytarowski wrote: > >On 08.06.2016 09:09, Martin Husemann wrote: > >> Maybe a minor nit: > >> > >> case _SC_THREAD_STACK_MIN: > >> - return _getpagesize(); > >> + return P

Re: PTHREAD_STACK_MIN support

2016-06-23 Thread Christos Zoulas
In article , Kamil Rytarowski 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 a

Re: PTHREAD_STACK_MIN support

2016-06-08 Thread Joerg Sonnenberger
On Wed, Jun 08, 2016 at 09:13:57AM +0200, Kamil Rytarowski wrote: > The point is to abstract this work to determine minimal stack size from > 3rd party software. That's an argument for providing the sysconf, but not for the static limit. Joerg

Re: PTHREAD_STACK_MIN support

2016-06-08 Thread Christos Zoulas
On Jun 8, 9:13am, n...@gmx.com (Kamil Rytarowski) wrote: -- Subject: Re: PTHREAD_STACK_MIN support | The point is to abstract this work to determine minimal stack size from | 3rd party software. | | Is defining it as per-port value correct? Are you worried that each port will return a

Re: PTHREAD_STACK_MIN support

2016-06-08 Thread Martin Husemann
On Wed, Jun 08, 2016 at 09:13:57AM +0200, Kamil Rytarowski wrote: > The point is to abstract this work to determine minimal stack size from > 3rd party software. I understand that. > Is defining it as per-port value correct? No, it is sometimes a runtime constant only. But of course we could pro

Re: PTHREAD_STACK_MIN support

2016-06-08 Thread Kamil Rytarowski
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 libpthr

Re: PTHREAD_STACK_MIN support

2016-06-08 Thread Martin Husemann
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 c

PTHREAD_STACK_MIN support

2016-06-07 Thread Charles Cui
Hi Christos, I have PTHREAD_STACK_MIN supported and attached patch for your review. My next step is to focus on the remaining part of signal (SIGPOLL, _SC_REALTIME_SIGNALS and _SC_SIGQUEUE_MAX). Seems we need much more significant changes in this part. Thanks, Charles 0003-add-PTHREAD_STAC

Re: PTHREAD_STACK_MIN support

2016-06-07 Thread Charles Cui
Cool! that's a really good idea, I will see whether SIGIO can replace SIGPOLL totally. Thanks for the advice! Charles. 2016-06-07 19:44 GMT-07:00 Christos Zoulas : > On Jun 7, 7:33pm, charles.cui1...@gmail.com (Charles Cui) wrote: > -- Subject: PTHREAD_STACK_MIN support > &

Re: PTHREAD_STACK_MIN support

2016-06-07 Thread Christos Zoulas
On Jun 7, 7:33pm, charles.cui1...@gmail.com (Charles Cui) wrote: -- Subject: PTHREAD_STACK_MIN support | Hi Christos, | |I have PTHREAD_STACK_MIN supported and attached | patch for your review. My next step is to focus on the remaining | part of signal (SIGPOLL, _SC_REALTIME_SIGNALS and