Section: 32.2.4 [thread.req.timing] Status: C++11 Submitter: LWG Opened: 2009-06-28 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [thread.req.timing].
View all issues with C++11 status.
Discussion:
Addresses UK 322, US 96
Description
Not all systems can provide a monotonic clock. How are they expected to treat a _for function?
Suggestion
Add at least a note explaining the intent for systems that do not support a monotonic clock.
Notes
Create an issue, together with UK 96. Note that the specification as is already allows a non-monotonic clock due to the word “should” rather than “shall”. If this wording is kept, a footnote should be added to make the meaning clear.
[ 2009-06-29 Beman provided a proposed resolution. ]
[ 2009-10-31 Howard adds: ]
Set to Tentatively Ready after 5 positive votes on c++std-lib.
[ 2010-02-24 Pete moved to Open: ]
LWG 1158's proposed resolution replaces the ISO-specified normative term "should" with "are encouraged but not required to", which presumably means the same thing, but has no ISO normative status. The WD used the latter formulation in quite a few non-normative places, but only three normative ones. I've changed all the normative uses to "should".
[ 2010-03-06 Beman updates wording. ]
[ 2010 Pittsburgh: Moved to Ready. ]
Proposed resolution:
Change Timing specifications 32.2.4 [thread.req.timing] as indicated:
The member functions whose names end in _for take an argument that
specifies a relative time. Implementations should use a monotonic clock to
measure time for these functions. [Note: Implementations are not
required to use a monotonic clock because such a clock may be unavailable.
— end note]