[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221119182842.GN29905@brightrain.aerifal.cx>
Date: Sat, 19 Nov 2022 13:28:42 -0500
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com>,
musl@...ts.openwall.com, Jason Ekstrand <jason@...kstrand.net>
Subject: Re: C23 implications for C libraries
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@...il.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
