View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00013461003.1(2016/18)/Issue7+TC2Base Definitions and Headerspublic2020-05-26 13:442024-06-11 09:08
Reportermarkh Assigned To 
PrioritynormalSeverityCommentTypeEnhancement Request
Status ClosedResolutionAccepted As Marked 
NameMark Harris
Organization
User Reference
Section1.7.1
Page Number8
Line Number236
Interp Status---
Final Accepted TextSee 0001346:0005157.
Summary0001346: Require support for CLOCK_MONOTONIC
DescriptionCLOCK_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 ActionFor 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().
Tagsissue8

Activities

Don Cragun

2020-12-03 17:21

manager   bugnote:0005157

Last edited: 2020-12-03 17:33

 All page and line numbers are against Issue 7 2018 edition (C181).

Delete page 8 lines 235-240 (XBD 1.7.1 Codes, MON) and remove the MON shading throughout:
  • page 426 lines 14470-14474 (XBD <time.h>)
  • page 511 lines 17861-17865 (XSH 2.8.5 Clocks and Timers)
  • page 512 line 17872 (XSH 2.8.5 Clocks and Timers)
  • page 590 lines 20564-20565 (XSH aio_suspend() description)
  • page 680 line 23320 (XSH clock_getres() errors)


On page 18 line 586 (XBD 2.1.3 POSIX Conformance), move _POSIX_MONOTONIC_CLOCK to a new list of symbolic constants for Issue 8 under page 17 line 552.

Delete page 23 line 818 and page 24 line 826.

On page 275 line 9235 (<limits.h>) change:
If the Monotonic Clock option is supported, the ...
to:
The ...

and remove the [MON] shading.

On page 436 lines 14851 - 14854, change
_POSIX_MONOTONIC_CLOCK
The implementation supports the Monotonic Clock option. If this symbol is defined in <unistd.h>, it shall be defined to be −1, 0, or 200809L. The value of this symbol reported by sysconf( ) shall either be −1 or 200809L.
to
_POSIX_MONOTONIC_CLOCK
The implementation supports a monotonic clock. This symbol shall always be set to the value 20yymmL.

and remove the [MON] shading.

On page 679 line 23272 (XSH clock_getres() description), change:
If the Monotonic Clock option is supported, all ...
to:
All ...


and remove the [MON] shading.

On page 1986 lines 63922-63923 (XSH sigtimedwait() ) change:
If the Monotonic Clock option is supported, the ...
to:
The ...


and remove the [MON] shading.

On page 2151 lines 68909-68910 change:
All implementations shall support a clock_id of CLOCK_REALTIME. If the Monotonic Clock option is supported, implementations shall support a clock_id of CLOCK_MONOTONIC.
to:
All implementations shall support CLOCK_REALTIME and CLOCK_MONOTONIC as values for clock_id.


and remove the [MON] shading.

On page 3485 line 117753 section A.2.1.3 change:
The following options from the previous version of this standard are now mandatory
to:
The following options from previous versions of this standard are now mandatory


and add _POSIX_MONOTONIC_CLOCK to the list following that text.

On page 3779 line 129738 section D.3.4, change:
The system supports the Monotonic Clock option.


This option ...
to:
Support for a monotonic clock is mandatory in POSIX.1-202x.


This facility ...

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
2020-12-03 17:21 Don Cragun Note Added: 0005157
2020-12-03 17:23 Don Cragun Interp Status => ---
2020-12-03 17:23 Don Cragun Final Accepted Text => See 0001346:0005157.
2020-12-03 17:23 Don Cragun Status New => Resolved
2020-12-03 17:23 Don Cragun Resolution Open => Accepted As Marked
2020-12-03 17:23 Don Cragun Tag Attached: issue8
2020-12-03 17:31 Don Cragun Note Edited: 0005157
2020-12-03 17:32 rhansen Note Edited: 0005157
2020-12-03 17:33 Don Cragun Note Edited: 0005157
2020-12-16 16:33 geoffclare Status Resolved => Applied
2024-06-11 09:08 agadmin Status Applied => Closed