[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221119153350.292e390b@inria.fr>
Date: Sat, 19 Nov 2022 15:33:50 +0100
From: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
To: "罗勇刚(Yonggang Luo)" <luoyonggang@...il.com>
Cc: musl@...ts.openwall.com, Jason Ekstrand <jason@...kstrand.net>
Subject: Re: C23 implications for C libraries
罗勇刚,
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?)
> When implement mesa vulkan driver,
> it's ask for CLOCK_MONOTONIC_RAW at
>
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L557
>
> May intention is using C2x timespec_get
> to replace function
> vk_clock_gettime but it's lack of TIME_MONOTONIC_RAW, so I don't know
> what's the best way
I am not sure why you'd want to do this, are you trying to port that
code such that it gets rid of any reference to POSIX interfaces? If
so, you'd have to wait and see if other C libraries will interface the
"new" time bases that C23 specifies. (Or does your code only run with
musl or windows?)
Then to know if a fallback to `CLOCK_MONOTONIC_RAW` is sensible, you
would have to inspect for which clocks the current function is really
used and if fallback is even needed in real life.
Jₑₙₛ
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
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.
