Re: Adding new pthread methods

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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:
> __POSIX2001_VISIBLE.

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?

--joel