From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18038 invoked from network); 19 Nov 2022 18:29:03 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Nov 2022 18:29:03 -0000 Received: (qmail 29758 invoked by uid 550); 19 Nov 2022 18:28:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29723 invoked from network); 19 Nov 2022 18:28:58 -0000 Date: Sat, 19 Nov 2022 13:28:42 -0500 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: =?utf-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= , musl@lists.openwall.com, Jason Ekstrand Message-ID: <20221119182842.GN29905@brightrain.aerifal.cx> References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221119153350.292e390b@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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) > ) 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