From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Helge Deller <deller@gmx.de>
Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH][RFC] clock_getres.2: Document that consecutive calls for CLOCK_MONOTONIC may return same values
Date: Sun, 23 Feb 2020 22:36:27 +0100 [thread overview]
Message-ID: <16ec6948-6a7c-5f48-d021-e7bb88ef786a@gmail.com> (raw)
In-Reply-To: <2c7b2576-0c5a-a40d-55c8-27cf28124767@gmx.de>
On 2/23/20 10:26 PM, Helge Deller wrote:
> On 23.02.20 22:09, Michael Kerrisk (man-pages) wrote:
>> Hello Helge,
>>
>> On 2/20/20 6:24 PM, Helge Deller wrote:
>>> Consecutive calls to clock_gettime(CLOCK_MONOTONIC) are guaranteed to
>>> return MONOTONIC values, which means that they either return the *SAME*
>>> time value like the last call, or a later (higher) time value.
>>>
>>> Due to high resolution counters like TSC on x86 most people see that the
>>> values returned increase, but on other less common platforms it's less
>>> likely that consecutive calls return newer values, and instead users may
>>> unexpectely get back the SAME time value.
>>>
>>> I think it makes sense to document that people should not expect to see
>>> "always-growing" time values. For example in Debian I've seen in quite
>>> some source packages where return values of consecutive calls are
>>> compared against each other and then the package build fails if they are
>>> equal (e.g. ruby-hitimes, ...).
>>>
>>> The patch below is just for RFC. I'm open for any better wording!
>>>
>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>
>>> diff --git a/man2/clock_getres.2 b/man2/clock_getres.2
>>> index 646fa37c0..89e9f6a30 100644
>>> --- a/man2/clock_getres.2
>>> +++ b/man2/clock_getres.2
>>> @@ -151,6 +151,10 @@ but is affected by the incremental adjustments performed by
>>> .BR adjtime (3)
>>> and NTP.
>>> This clock does not count time that the system is suspended.
>>> +All
>>> +.B CLOCK_MONOTONIC
>>> +variants guarantee that the time returned by consecutive calls will not go
>>> +backwards, but they may return the identical (not-increased) time value.
>>> .TP
>>> .BR CLOCK_MONOTONIC_COARSE " (since Linux 2.6.32; Linux-specific)"
>>> .\" Added in commit da15cfdae03351c689736f8d142618592e3cebc3
>>
>> Thanks. I applied your patch, and then tweaked slightly, so
>> tha the change looks as below.
>
>
> Looks good.
> Thanks!
Thanks for checking!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
prev parent reply other threads:[~2020-02-23 21:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 17:24 [PATCH][RFC] clock_getres.2: Document that consecutive calls for CLOCK_MONOTONIC may return same values Helge Deller
2020-02-23 21:09 ` Michael Kerrisk (man-pages)
2020-02-23 21:26 ` Helge Deller
2020-02-23 21:36 ` Michael Kerrisk (man-pages) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16ec6948-6a7c-5f48-d021-e7bb88ef786a@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=deller@gmx.de \
--cc=john.stultz@linaro.org \
--cc=linux-man@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.