Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: PTHREAD_STACK_MIN support
1 view
Skip to first unread message
Christos Zoulas
Jun 7, 2016, 10:44:46 PM6/7/16
to
On Jun 7, 7:33pm, charles...@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 _SC_SIGQUEUE_MAX).
| Seems we need much more significant changes in this part.
Yup, that looks good. Which one do you want to do first?
Try:
#define SIGPOLL SIGIO
and see where that gets you :-)
christos
-- 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 _SC_SIGQUEUE_MAX).
| Seems we need much more significant changes in this part.
Yup, that looks good. Which one do you want to do first?
Try:
#define SIGPOLL SIGIO
and see where that gets you :-)
christos
Charles Cui
Jun 8, 2016, 12:44:41 AM6/8/16
to
Cool! that's a really good idea, I will see whether SIGIO can replace
SIGPOLL totally.
Thanks for the advice!
Charles.
SIGPOLL totally.
Thanks for the advice!
Charles.
Martin Husemann
Jun 8, 2016, 3:10:09 AM6/8/16
to
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
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
Kamil Rytarowski
Jun 8, 2016, 3:14:14 AM6/8/16
to
3rd party software.
Is defining it as per-port value correct?
Martin Husemann
Jun 8, 2016, 3:17:55 AM6/8/16
to
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.
> The point is to abstract this work to determine minimal stack size from
> 3rd party software.
> Is defining it as per-port value correct?
provide a per-arch maximal value and use that.
Martin
Christos Zoulas
Jun 8, 2016, 9:21:43 AM6/8/16
to
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.
|
matter.
christos
-- 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 different value? That does not
matter.
christos
Joerg Sonnenberger
Jun 8, 2016, 10:10:08 AM6/8/16
to
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
> 3rd party software.
limit.
Joerg
0 new messages