From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Bart Van Assche" <bart.vanassche@gmail.com>
Cc: "Michael Kerrisk" <mtk.manpages@gmail.com>,
lkml <linux-kernel@vger.kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"john stultz" <johnstul@us.ibm.com>,
"Ingo Molnar" <mingo@elte.hu>,
"Roman Zippel" <zippel@linux-m68k.org>
Subject: Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?
Date: Tue, 24 Jun 2008 07:18:47 +0200 [thread overview]
Message-ID: <cfd18e0f0806232218n3abfa334hd0c743c8efba872@mail.gmail.com> (raw)
In-Reply-To: <e2e108260806230456w1b1faa0ftd2c8a4114dbdd89@mail.gmail.com>
On Mon, Jun 23, 2008 at 1:56 PM, Bart Van Assche
<bart.vanassche@gmail.com> wrote:
> On Mon, Jun 23, 2008 at 11:48 AM, Michael Kerrisk
> <mtk.manpages@googlemail.com> wrote:
>> On Mon, Jun 23, 2008 at 10:34 AM, Bart Van Assche
>> <bart.vanassche@gmail.com> wrote:
>>> On Sun, Jun 22, 2008 at 9:35 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>>> The POSIX.1 specification of nanosleep() says:
>>>>
>>>> But, except for the case of being interrupted by a signal, the
>>>> suspension time shall not be less than the time specified by
>>>> rqtp, as measured by the system clock CLOCK_REALTIME.
>>>>
>>>>
>>>> However, reading kernel/hrtimer.c:sys_nanosleep(), it appears that
>>>> CLOCK_MONOTONIC is used.
>>>>
>>>> return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
>>>>
>>>> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME? Is it
>>>> intentional? If yes, then I should document this in the man-pages. If not,
>>>> then it should be fixed.
>>>
>>> CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
>>> backward, CLOCK_REALTIME not. So the man page should be fixed.
>>
>> Thanks for your reply, but I'm not quite convinced yet. The things
>> is: the Solaris man page also says "CLOCK_REALTIME". (Of course that
>> man page may just be parroting the standard.) Could there not be some
>> reasonable semantics for a nanosleep() that was based on
>> CLOCK_REALTIME?
>
> Sorry, but I don't think that a nanosleep() based on CLOCK_REALTIME
> would have reasonable semantics. The first line of the description in
> nanosleep()'s manpage says:
> "nanosleep() delays the execution of the program for at least the
> time specified in *req". So you really need CLOCK_MONOTONIC and not
> CLOCK_REALTIME.
I meant to add. It seems to me that there really could be reasonable
semantics here: nanosleep() sleeps until the specified time has
elapsed, as measured by CLOCK_REALTIME. That may mean, for example,
that the sleep finishes "early" if CLOCK_REALTIME jumps forward for
some reason. That seems perfectly reasonable as possible semantics
for sleeping (i.e., we are interested in sleeping for an interval
based on what the system understands the time to be in the "outside
world"). Note that POSIX also specifies clcok_nanosleep(), which
allows CLOCK_REALTIME and CLOCK_MONOTONIC, and is again explicit about
what nanosleep() should be doing:
APPLICATION USAGE
Calling clock_nanosleep() with the value TIMER_ABSTIME not set
in the flags argument and with a clock_id of CLOCK_REALTIME is
equivalent to calling nanosleep() with the same rqtp and rmtp
arguments.
RATIONALE
The nanosleep() function specifies that the system-wide clock
CLOCK_REALTIME is used to measure the elapsed time for this
time service. However, with the introduction of the monotonic
clock CLOCK_MONOTONIC a new relative sleep function is needed
to allow an application to take advantage of the special char-
acteristics of this clock.
Cheers,
Michael
next prev parent reply other threads:[~2008-06-24 5:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-22 7:35 Michael Kerrisk
2008-06-23 8:34 ` Bart Van Assche
2008-06-23 9:48 ` Michael Kerrisk
2008-06-23 11:56 ` Bart Van Assche
2008-06-24 5:08 ` Michael Kerrisk
2008-06-24 5:18 ` Michael Kerrisk [this message]
2008-06-23 12:43 ` Roman Zippel
2008-06-24 5:39 ` Michael Kerrisk
2008-06-24 8:01 ` Bart Van Assche
2008-06-24 8:27 ` Michael Kerrisk
2008-06-24 9:27 ` Bart Van Assche
2008-06-24 9:31 ` Michael Kerrisk
2008-06-25 6:13 ` Thomas Gleixner
2008-06-25 6:16 ` Michael Kerrisk
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=cfd18e0f0806232218n3abfa334hd0c743c8efba872@mail.gmail.com \
--to=mtk.manpages@googlemail.com \
--cc=bart.vanassche@gmail.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtk.manpages@gmail.com \
--cc=tglx@linutronix.de \
--cc=zippel@linux-m68k.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®