mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®