What clocks are supported by pthread_clockjoin_np()

[Adhemerval Zanella]

On 19/11/2020 09:00, Mike Crowe via Libc-alpha wrote:
> On Thursday 19 November 2020 at 09:42:07 +0100, Michael Kerrisk (man-pages) wrote:
>> I was looking at adding manual page documentation for
>> pthread_clockjoin_np(), but it's not clear to me from the code what
>> clocks are supported by the API, and the glibc info docs seem to be
>> silent on this point. What clocks are supported?
> 
> That's an interesting question. My intention was that it would support
> CLOCK_REALTIME and CLOCK_MONOTONIC just like pthread_cond_clockwait,
> sem_clockwait etc.

I think it does make sense to align with other pthread/rt implementations.

> 
> However, since the current implementation currently just calls
> clock_gettime to calculate a relative timeout to pass to futex it will work
> with any clock that clock_gettime supports.
> 
> Perhaps we ought to document pthread_clockjoin_np as supporting only
> CLOCK_REALTIME and CLOCK_MONOTONIC and then change the implementation to
> fail with EINVAL on any other clocks? Doing this means that the
> implementation can switch to passing an absolute timeout to futex in the
> future, which would mean that warping of CLOCK_REALTIME would be honoured
> correctly by the kernel (although it's not clear to me how important that
> really is to anyone.)

There is another related issue on which error to return for clock not
available to used with the syscall, for instance pthread_mutex_clocklock/PI 
with CLOCK_MONOTONIC (BZ #26801 [1]). My take is to return ENOTSUP, however
as Florian has raised, I am not sure if this is the correct return code.

[1] https://sourceware.org/pipermail/libc-alpha/2020-October/119211.html