linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Crowe <mac@mcrowe.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: linux-man <linux-man@vger.kernel.org>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: What clocks are supported by pthread_clockjoin_np()
Date: Thu, 19 Nov 2020 12:00:34 +0000	[thread overview]
Message-ID: <20201119120034.GA20599@mcrowe.com> (raw)
In-Reply-To: <CAKgNAkj26iqAZoez08YVmA-u0fWAvDV9DcctM4hRHhAjwpvcvQ@mail.gmail.com>

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.

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

Thanks.

Mike.

      reply	other threads:[~2020-11-19 12:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19  8:42 What clocks are supported by pthread_clockjoin_np() Michael Kerrisk (man-pages)
2020-11-19 12:00 ` Mike Crowe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201119120034.GA20599@mcrowe.com \
    --to=mac@mcrowe.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).