What clocks are supported by pthread_clockjoin_np()

[Mike Crowe]

On Thursday 19 November 2020 at 09:29:55 -0300, Adhemerval Zanella via Libc-alpha wrote:
> 
> 
> 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.

OK. I shall prepare a patch to reject anything other than CLOCK_REALTIME
and CLOCK_MONOTONIC.

> > 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

The wording[2] destined for POSIX says to return EINVAL in this situation.
I originally tried to return different errors for different types of
incorrect clock[3], but I thought that doing so would be prone to errors
and no-one seemed to disagree.

(I don't read libc-alpha regularly, so feel free to email me directly if
this topic comes up again.)

Thanks.

Mike.

[2] https://www.austingroupbugs.net/view.php?id=1216#c4478
[3] https://www.austingroupbugs.net/view.php?id=1216#c4196