This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread.h

On 07/08/2013 06:58 PM, Ralf Corsepius wrote:
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[1][2].


[1] 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.

[2] IIRC, bootstrapping GCC also requires for targets which actually support
pthreads. For newlib, to my knowledge this would be cygwin and RTEMS, only.

How do we want to proceed with this?

1. Move "newlib/libc/include/pthread.h" to "?".

2. Perform RTEMS specific updates of pthread.h?

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  :
PGP     : Public key available on request.

Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]