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: Adding new pthread methods

On 2/15/2016 1:38 PM, Yaakov Selkowitz wrote:
On 2016-02-15 13:05, Joel Sherrill wrote:
I am planning to add a few new pthread methods to RTEMS.
My question on each is what feature guard conditions should
be around them.

The Linux man-pages don't indicate any guards for these functions,
however that would not seem to be correct.

+ pthread_condattr_getclock and pthread_condattr_setclock
first appeared in Issue 6 and per the Open Group page was
derived from IEEE Std 1003.1j-2000.

+ pthread_getcpuclockid was first in Issue 6 and was
derived from IEEE Std 1003.1d-1999

The Linux feature test macros do not appear to recognize any steps
between POSIX.1c (199506L) and POSIX.1-2001 (200112L).  Therefore,
unless we create such granularity, in my proposed rework:

That's probably OK. But steps for the versions after 2001 should
be honored.

+ pthread_setschedprio was first in Issue 6.

In my proposed rework: __POSIX2001_VISIBLE.

OK. I will wait until your patches settle before doing this.

I didn't mention pthread_setconcurrency() but it is also on my
list even though it is marked obsolete in Issue 7. It would be
added under the same guard.

But pthread_attr_[gs]etstackaddr() are marked removed in Issue 7
so would your pattern add a !__POSIX2013_VISIBLE?


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