Date: Sun, 20 Nov 2022 01:19:40 +0800 From: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com> To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> Cc: musl@...ts.openwall.com, Jason Ekstrand <jason@...kstrand.net> Subject: Re: C23 implications for C libraries On Sat, Nov 19, 2022 at 10:33 PM Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> 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) I like this list, as It doesn't have to be implemented, have such a complete list in C2x standard is very good > > 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?) Yeap, I want to gets rid of any reference to POSIX interfaces, as I am writing code shared between windows and linux or even more platforms(with or without posix support）, And I am implementing timespec_get in mesa code base to avoid waiting c23 or future c2x to be implemented by c standard library provider, currently for mesa's special usage, We need access to CLOCK_REALTIME CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW, so the equivalent TIME_UTC, TIME_MONOTONIC, TIME_MONOTONIC_RAW in Cx standard is good. > > 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 :: -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo Content of type "text/html" 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.