Messages in this thread | | | Date | Tue, 24 Jun 2008 07:39:41 +0200 | From | "Michael Kerrisk" <> | Subject | Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME? |
| |
Roman,
On Mon, Jun 23, 2008 at 2:43 PM, Roman Zippel <zippel@linux-m68k.org> wrote: > Hi, > > On Mon, 23 Jun 2008, Michael Kerrisk wrote: > >> >> 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? > > CLOCK_MONOTONIC is optional, that's probably the reason it's not mentioned > there.
This seems a little unlikely. POSIX specifies clock_nanosleep() (see my other reply) specifically to allow for clocks other than CLOCK_REALTIME.
> If you check the man page for clock_settime, it specifically > mentions that pending relative timer (including nanosleep) aren't affected > by the changed time, thus if CLOCK_MONOTONIC and CLOCK_REALTIME advance > equally, it doesn't matter which you use for relative timer.
Well, I was going to say that that's just a man page, and man page authors are fallible ;-). But then I went and had a look at the POSIX spec for clock_settime(). It includes the following paragraph:
Setting the value of the CLOCK_REALTIME clock via clock_set- time() shall have no effect on threads that are blocked waiting for a relative time service based upon this clock, including the nanosleep() function; nor on the expiration of relative timers based upon this clock. Consequently, these time services shall expire when the requested relative interval elapses, independently of the new or old value of the clock.
So that rather flatly contradicts the alternative semantics that I suggested were possible in my reply to Bart a few minutes ago.
So in my reading of things now, it looks as though the Linux implementation is probably fine, since the fact that relative timers/sleeps are explicitly unaffected by jumps in CLOCK_REALTIME means that the semantics are effectively the same as if the relative interval was measured against CLOCK_MONOTONIC (unless the two clocks counted time at different rates; not sure if that would be possible in theory, but certainly seems very unlikely in practice).
I'll add some text (not quite sure what yet) in the nanosleep() man page on this point.
Thanks Roman, Bart.
Cheers,
Michael
-- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
| |