mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: "Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>
Cc: "罗勇刚(Yonggang Luo)" <luoyonggang@gmail.com>,
	musl@lists.openwall.com, "Jason Ekstrand" <jason@jlekstrand.net>
Subject: Re: [musl] C23 implications for C libraries
Date: Sat, 19 Nov 2022 13:28:42 -0500	[thread overview]
Message-ID: <20221119182842.GN29905@brightrain.aerifal.cx> (raw)
In-Reply-To: <20221119153350.292e390b@inria.fr>

On Sat, Nov 19, 2022 at 03:33:50PM +0100, Jₑₙₛ Gustedt wrote:
> 罗勇刚,
> 
> on Sat, 19 Nov 2022 04:46:22 +0800 you (罗勇刚(Yonggang Luo)
> <luoyonggang@gmail.com>) wrote:
> 
> > There is a concept called CLOCK_MONOTONIC_RAW  (since Linux 2.6.28;
> > Linux-specific),
> > May C2x provide TIME_MONOTONIC_RAW in future or can we just implement
> >  TIME_MONOTONIC with
> > CLOCK_MONOTONIC_RAW  on Linux?
> 
> I am not completely sure what you are asking. C2x was the short name
> for C23 when we did not yet know that it will come out in 2023.
> 
> C23 indeed adds three *optional* time bases `TIME_MONOTONIC`,
> `TIME_ACTIVE` and `TIME_THREAD_ACTIVE` which are modeled after the
> POSIX clocks `CLOCK_MONOTONIC`, `CLOCK_PROCESS_CPUTIME_ID` and
> `CLOCK_THREAD_CPUTIME_ID`, respectively. Using them to map to other
> POSIX clocks, even if these are conceptually close, is not a good
> idea, I think.
> 
> That said, having time bases for C other than `TIME_UTC` is at the
> liberty of the implementation, so musl could easily provide the
> equivalent to all POSIX clocks that it interfaces. Currently these are
> 
> #define CLOCK_REALTIME           0
> #define CLOCK_MONOTONIC          1
> #define CLOCK_PROCESS_CPUTIME_ID 2
> #define CLOCK_THREAD_CPUTIME_ID  3
> #define CLOCK_MONOTONIC_RAW      4
> #define CLOCK_REALTIME_COARSE    5
> #define CLOCK_MONOTONIC_COARSE   6
> #define CLOCK_BOOTTIME           7
> #define CLOCK_REALTIME_ALARM     8
> #define CLOCK_BOOTTIME_ALARM     9
> #define CLOCK_SGI_CYCLE         10
> #define CLOCK_TAI               11
> 
> This could easily be done by using
> 
> #define TIME_UTC              (CLOCK_REALTIME+1)
> #define TIME_MONOTONIC        (CLOCK_MONOTONIC+1)
> #define TIME_ATIVE            (CLOCK_PROCESS_CPUTIME_I+1)
> #define TIME_THREAD_ACTIVE    (CLOCK_THREAD_CPUTIME_ID+1)
> #define TIME_MONOTONIC_RAW    (CLOCK_MONOTONIC_RAW+1)
> #define TIME_UTC_COARSE       (CLOCK_REALTIME_COARSE+1)
> #define TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1)
> #define TIME_BOOTTIME         (CLOCK_BOOTTIME+1)
> #define TIME_UTC_ALARM        (CLOCK_REALTIME_ALARM+1)
> #define TIME_BOOTTIME_ALARM   (CLOCK_BOOTTIME_ALARM+1)
> #define TIME_SGI_CYCLE        (CLOCK_SGI_CYCLE+1)
> #define TIME_TAI              (CLOCK_TAI+1)
> 
> and then adapting `timespec_get` a bit. This would be conforming to
> current and future C, because the `TIME_` prefix is already reserved
> for that purpose.
> 
> Unfortunately the choice of the values is an ABI choice, so before
> doing so we should be sure that other C libraries on Linux use the
> same values.
> 
> (Rich: would you accept a patch that goes in that direction?)

I don't see any good reason to have extension clocks in the
timespec_get interface unless they're destined for standardization.
It's just a risk of conflict with future standards requirements.
There's really no reason at all to even use this interface rather than
the POSIX one unless you're writing code that's targeting baseline C
(and especially C11 threads, where having a timespec is sometimes
useful for those interfaces) with the aim of also operating on
non-POSIX-like implementations, and it doesn't seem like you would
expect such a target to have Linux-like extension clocks.

Rich

  parent reply	other threads:[~2022-11-19 18:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-23 14:25 Jₑₙₛ Gustedt
2022-09-23 14:58 ` Rich Felker
2022-09-23 15:11   ` Alexander Monakov
2022-09-23 15:35   ` Jₑₙₛ Gustedt
2022-09-23 15:28 ` enh
2022-09-23 15:40   ` Jₑₙₛ Gustedt
2022-09-23 23:52     ` enh
2022-09-24  7:31       ` Jₑₙₛ Gustedt
2022-09-26  3:18         ` Damian McGuckin
2022-09-26  3:33         ` Rich Felker
2022-09-26 10:49         ` Florian Weimer
2022-09-26 12:52           ` Jₑₙₛ Gustedt
2022-09-26 20:13         ` enh
2022-11-18 20:46 ` 罗勇刚(Yonggang Luo)
2022-11-19 14:33   ` Jₑₙₛ Gustedt
2022-11-19 17:19     ` 罗勇刚(Yonggang Luo)
2022-11-20  8:23       ` Jₑₙₛ Gustedt
2022-11-19 18:28     ` Rich Felker [this message]
2022-11-20  8:42       ` Jₑₙₛ Gustedt
2023-05-03 22:58     ` enh
2023-05-04  6:19       ` Jₑₙₛ Gustedt
2023-05-04 16:03         ` Rich Felker
2023-05-04 16:07           ` enh
2023-05-04 23:16             ` Gabriel Ravier
2023-05-05  0:37               ` JeanHeyd Meneide
2023-05-05  6:56                 ` Jₑₙₛ Gustedt
2023-05-05 12:40                   ` Rich Felker
2023-05-05  6:40             ` Jₑₙₛ Gustedt
2023-05-04 16:03         ` enh
2023-05-04 23:11           ` Gabriel Ravier
2022-11-19 18:31   ` Rich Felker
2022-11-20  4:25     ` 罗勇刚(Yonggang Luo)
2022-11-20  5:34       ` Markus Wichmann
2022-11-21 11:46 ` Reini Urban
2022-11-21 21:06   ` Jₑₙₛ Gustedt
2022-11-23  4:31     ` 罗勇刚(Yonggang Luo)
2022-11-23  8:11       ` Jₑₙₛ Gustedt
2022-11-23  8:20         ` 罗勇刚(Yonggang Luo)
2022-11-23  8:33           ` Jₑₙₛ Gustedt
2022-11-23  8:41             ` 罗勇刚(Yonggang Luo)

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=20221119182842.GN29905@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=jason@jlekstrand.net \
    --cc=jens.gustedt@inria.fr \
    --cc=luoyonggang@gmail.com \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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