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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24418 invoked from network); 20 Nov 2022 08:42:48 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Nov 2022 08:42:48 -0000 Received: (qmail 26198 invoked by uid 550); 20 Nov 2022 08:42:45 -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 26164 invoked from network); 20 Nov 2022 08:42:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version; bh=0afL0uF03jsLhSEf/zFmQw3V1eVH+YaAwP99NLTwFFE=; b=p7k5hy2M112JyIA11tYDkkRs6gRCTnOymC9ftiMJPDuqdQ2RUsykFvyn +rIf2nyo+ThiYx7Xd9bIp/DzfdehZaBYlPlTEWW0O4FECM1URHL2Zd7SI wKmYhj2FMNX+AfTDb6I9AwKyKEP9z572ydiNzNLb191/BpVwt1tGRDxE8 E=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="5.96,179,1665439200"; d="scan'208";a="79111554" Date: Sun, 20 Nov 2022 09:42:32 +0100 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: "=?UTF-8?B?572X5YuH5Yia?=(Yonggang Luo)" , musl@lists.openwall.com, Jason Ekstrand Message-ID: <20221120094232.01f4f20b@inria.fr> In-Reply-To: <20221119182842.GN29905@brightrain.aerifal.cx> References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> <20221119182842.GN29905@brightrain.aerifal.cx> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/3T+6lLKVWWN2OTJTdR4Mlws"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] C23 implications for C libraries --Sig_/3T+6lLKVWWN2OTJTdR4Mlws Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rich, on Sat, 19 Nov 2022 13:28:42 -0500 you (Rich Felker ) wrote: > On Sat, Nov 19, 2022 at 03:33:50PM +0100, J=E2=82=91=E2=82=99=E2=82=9B Gu= stedt wrote: > > =E7=BD=97=E5=8B=87=E5=88=9A, > >=20 > > on Sat, 19 Nov 2022 04:46:22 +0800 you (=E7=BD=97=E5=8B=87=E5=88=9A(Yon= ggang Luo) > > ) wrote: > > =20 > > > 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? =20 > >=20 > > 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. > >=20 > > 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. > >=20 > > 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 > >=20 > > #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 > >=20 > > This could easily be done by using > >=20 > > #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) > >=20 > > 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. > >=20 > > 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. > >=20 > > (Rich: would you accept a patch that goes in that direction?) =20 >=20 > 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=E2=82=91=E2=82=99=E2=82=9B --=20 :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/3T+6lLKVWWN2OTJTdR4Mlws Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCY3noeAAKCRAP0+hp2tU3 4v7lAJ9w5ROVasS+FLLSPcN9ZZCiRmezywCcDI/T/MqGvYtzyxDG63rzWSmdIi4= =zWUA -----END PGP SIGNATURE----- --Sig_/3T+6lLKVWWN2OTJTdR4Mlws--