[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Apr 2023 11:14:36 +0100
From: Jonathan Wakely <jwakely@...hat.com>
To: libc-coord@...ts.openwall.com
Subject: Relation between C timespec_get time bases and POSIX clockid_t values.
C11 added timespec_get and the constant TIME_UTC. POSIX extends this by
requiring TIME_UTC to use the same clock as CLOCK_REALTIME. However,
TIME_UTC is required to be non-zero, and CLOCK_REALTIME is zero on existing
implementations.
C23 adds TIME_MONOTONIC, and (optionally supported) TIME_ACTIVE and
TIME_THREAD_ACTIVE. Presumably a future version of POSIX will say those use
the same clocks as CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID and
CLOCK_THREAD_CPUTIME_ID respectively.
It would be helpful if POSIX guaranteed that every C time base can be
converted to a POSIX clockid_t by adding the constant value (TIME_UTC -
(int)CLOCK_REALTIME). This would allow programs using both timespec_get and
clock_gettime to use a single value for a given clock, and easily convert
to the other domain. For example, a program using timespec_get in one
module (which might be written in portable ISO C) might want to pass a
clock to pthread_cond_timedwait in another module (written in POSIX C).
This could also be relevant to a proposed C++ extension that would expose
the underlying clock used by C++ clocks such as std::chrono::system_clock
and std::chrono::steady_clock (see
https://lists.isocpp.org/std-proposals/2023/04/6379.php for details).
In the absence of a POSIX guarantee, it would be helpful if C libraries
guaranteed how to convert a C time base to a POSIX clockid_t ASAP.
Is that practical to guarantee today? Are there any implementations that
already support C bases other than TIME_UTC, where the mapping from
TIME_foo to CLOCK_foo is not a simple addition?
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.
