The following issue has been SUBMITTED. ====================================================================== https://www.austingroupbugs.net/view.php?id=1346 ====================================================================== Reported By: markh Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1346 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Mark Harris Organization: User Reference: Section: 1.7.1 Page Number: 8 Line Number: 236 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2020-05-26 13:44 UTC Last Modified: 2020-05-26 13:44 UTC ====================================================================== Summary: Require support for CLOCK_MONOTONIC Description: CLOCK_MONOTONIC was introduced in Issue 6, but only as an optional feature. However many applications require the use of a clock that cannot have negative time jumps.
A monotonic clock is not an obscure feature, and is widely available via non-POSIX interfaces. For example, C++ applications (since C++11) can rely on std::chrono::steady_clock, Java applications (since Java 7) can rely on System.nanoTime(), Python applications (since Python 3.5) can rely on time.monotonic(), macOS and iOS applications can rely on mach_absolute_time(), and Windows applications (since Windows 2000) can rely on QueryPerformanceCounter(). Many applications targeting POSIX just assume that CLOCK_MONOTONIC is available, but others that are trying to be more portable use checks that are difficult to get right and test, and may still fail on a system conforming to the latest revision of POSIX if CLOCK_MONOTONIC works with some interfaces (like clock_gettime()) but not others (like clock_nanosleep()). The addition of new interfaces such as pthread_cond_clockwait() (#1216) will make correct checking even more complex for applications that wish to use the new interfaces, but also support the possibility allowed by the standard that they may not be usable with CLOCK_MONOTONIC. A properly functioning monotonic clock is important and applications relying on Issue 8 should not be burdened with additional checks or fallbacks; they should be able to rely on a monotonic clock being available, as C++ applications, Java applications, Python applications, and macOS, iOS, and Windows applications have been able to do for years. Desired Action: For Issue 8, require support for the Monotonic Clock option, and require that CLOCK_MONOTONIC be supported by all standard interfaces that accept a clock id except clock_settime(). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2020-05-26 13:44 markh New Issue 2020-05-26 13:44 markh Name => Mark Harris 2020-05-26 13:44 markh Section => 1.7.1 2020-05-26 13:44 markh Page Number => 8 2020-05-26 13:44 markh Line Number => 236 ======================================================================
