[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221120094232.01f4f20b@inria.fr>
Date: Sun, 20 Nov 2022 09:42:32 +0100
From: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
To: Rich Felker <dalias@...c.org>
Cc: "罗勇刚(Yonggang Luo)" <luoyonggang@...il.com>,
musl@...ts.openwall.com, Jason Ekstrand <jason@...kstrand.net>
Subject: Re: C23 implications for C libraries
Rich,
on Sat, 19 Nov 2022 13:28:42 -0500 you (Rich Felker <dalias@...c.org>)
wrote:
> 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.
Ok, I see your point, kind of, but we could still interface these by
appending `_NP` or so to the name. This is low cost service to maybe
some users. And the Linux extensions will not go away, so there should
not be any extra burden by doing so.
Put that questions about extensions aside, three of them become
options in C23. So for those there is no reason to hold back, right?
> 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.
For the usefulness of the C thread interface, I don't agree. That
interface is much simpler and tamer than the POSIX interface and
completely sufficient for a large spectrum of applications. Of what I
observed 80% of the effort of implementing POSIX threads in musl went
into the necessary support of thread cancelation. This is a large
source of problems, bugs and maybe even slight performance costs.
Then for the usefulness of the `timespec` interfaces this is exactly
the point. These only become useful if per default there are more time
bases supported, such that they can replace the other cryptic
interfaces for timing (such as the non-portable `clock` function) that
we inherited from the elders. Therefore C23 also adds
`timespec_getres` such that applications have a sensible way of using
these for timing, independently of the thread interface.
Thanks
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.
