mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: linux@horizon.com
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 'select' failure or signal should not update timeout
Date: 28 Jul 2002 10:33:11 -0000	[thread overview]
Message-ID: <20020728103311.25018.qmail@science.horizon.com> (raw)

Chris Friesen asked for:
> waitonmonotonicallyincreasingnonadjustablehighres64bittime()

Well, take the POSIX clock_gettime() interface and add clock_waittime().
Oh, wait.. they already did it.  clock_nanosleep().

The POSIX folks realized that people want a variety of tiemrs, and
so the functions take a clockid_t first argument, which is just an enum.
They defined two values, but leave the field open to others:
- CLOCK_MONOTONIC, which is what you want.  Unspecified epoch
  (possibly boot time), and never gets adjusted
- CLOCK_REALTIME, which is the classig time() UTC time.

Extensions define CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID.

The clock weenies are welcome to add CLOCK_TAI, CLOCK_GPS, CLOCK_UTS
(see Markus Kuhn's suggestion), CLOCK_UTC (with some "better" leap-second
handling), CLOCK_FREQADJUST (uses frequency but not phase adjustments),
CLOCK_NOSTEP (frequency and phase adjustments, but doesn't step),
and anything else you like.

Astronomers might add CLOCK_UT1, CLOCK_UT0, CLOCK_SIDERIAL, CLOCK_TDB,
CLOCK_TDT, CLOCK_TCG, CLOCK_TCB, and maybe a few things I haven't thought
of.  The interface doesn't require that all of these be implemented in
the kernel, of course.

             reply	other threads:[~2002-07-28 10:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-28 10:33 linux [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-07-21  3:34 Peter T. Breuer
2002-07-20  3:59 dank
     [not found] <200207171430.g6HEUvY23619@aztec.santafe.edu>
2002-07-19  9:52 ` Paul Eggert
2002-07-20  0:38   ` Alan Cox
2002-07-20  5:57     ` Linus Torvalds
2002-07-21 15:36       ` Eric W. Biederman
2002-07-24 13:44         ` Jamie Lokier
2002-07-24 18:48           ` Linus Torvalds
2002-07-24 19:07             ` Chris Friesen
2002-07-24 23:30             ` Jamie Lokier
2002-07-25  6:32             ` Rusty Russell
2002-07-25 18:31               ` george anzinger
2002-07-28  5:40               ` David Schwartz
2002-07-25 16:35             ` Eric W. Biederman
2002-07-25 17:15               ` Jamie Lokier
2002-07-21 16:00       ` Christoph Rohland
2002-07-21 16:43         ` Linus Torvalds
2002-07-21 17:51           ` dean gaudet
2002-07-22  3:59           ` Edgar Toernig
2002-07-22  6:51           ` Christoph Rohland
2002-07-21 16:26       ` Ingo Molnar
2002-07-21 20:14     ` Richard Stallman

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=20020728103311.25018.qmail@science.horizon.com \
    --to=linux@horizon.com \
    --cc=linux-kernel@vger.kernel.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®