This is the mail archive of the
mailing list for the newlib project.
- From: Ralf Corsepius <ralf dot corsepius at rtems dot org>
- To: newlib at sourceware dot org
- Date: Mon, 08 Jul 2013 18:58:03 +0200
- Subject: Re: pthread.h
- References: <f5qchu8cm5v3nh4104qinwms dot 1372951564676 at email dot android dot com> <20130705091931 dot GD4009 at calimero dot vinschen dot de>
On 07/05/2013 11:19 AM, Corinna Vinschen wrote:
On Jul 4 10:26, Joel Sherrill wrote:
Following up.. In general what should be done about adding np methods?
All of the thread affinity services are beyond POSIX at this point add
is getting the pthread attributes. As we consider adding these
methods, what is the guidance?
I think there's not much speaking against adding _np functions if their
declaration is guarded by !_POSIX_SOURCE or _GNU_SOURCE.
Just picking up this mail from this torn apart thread, to reply:
The more I think about newlib's pthread.h, the more I think it should be
removed from newlib rsp. moved into newlib's rtems/ directory, because I
believe nobody but RTEMS uses it.
 Grepping the source tree tells, the cris port also seems to use it,
but I am inclined to believe this to be a bug, because I am having
difficulties to imagine what a bare-metal target would need pthread.h for.
 IIRC, bootstrapping GCC also requires for targets which actually
support pthreads. For newlib, to my knowledge this would be cygwin and