Paul Eggert wrote on 1999-08-29 11:04 UTC:
True, but (1) in practice many people set the clock directly, without using adjtime, and (2) even adjtime can mess up benchmarks, the application domain that you proposed gettimeofday for. With gettimeofday, one must make sure that nobody adjusts the system's notion of the time of day while you're doing benchmarks. With TIME_MONOTONIC, you needn't worry about adjustments to the system clock.
The guaranteed continuity of TIME_MONOTONIC is one reason for the existence of this separate clock type. This property is a very welcome (and sometimes formally required!) assurance for the designer of safety-critical system, who is not allowed to assume that the real-world user knows, which type of resetting the clock is legal and which is not. Embedded systems are in the real world often operated accidentally with dates that are years off, and when people find out, they want to be able to fix this immediately, without messing up safety-critical processes while doing so. You all should have heard by know about the various near-catastrophes that dumb Y2K tests have caused because the software was not prepared to handle non-monotonicity. There definitely is a requirement for at leat two clock types, one guaranteed to run always and freely, the other providing a best-effort approximation of an external scale such as say UTC, TAI, or whatever the available local time happens to be. But that is not all. A second reason are small embedded systems (industrial automation controllers (e.g., chemical and pharmaceutical industry) are frequently quoted examples) that have no battery-powered clock and that get their first opportunity to sync with an external time scale (if at all) only considerable time after they booted. There are safety critical applications that need guaranteed precise relative interval timing right after system start-up, no matter whether the GPS antenna happens to be pointing in the right direction etc., and TIME_MONOTONIC is intended for these as well. This was an industrial requirement documented in the POSIX process when the POSIX real-time extensions group considered revising the clock definition to something not to far away from my xtime_get. And yes, these are real world safety and security requirements in embedded realtime systems, in which the C API is very widely used today, and where it is far from being satisfactory. Not every large-scale C implementation underlies assumptions that might be perfectly valid for Dan's desktop workstation. "D. J. Bernstein" <djb@cr.yp.to> wrote on 1999-08-29:
Who cares? Remember that the point of libtai is to support real programs, not to build an API in the sky.
Dan, did you ever work with an FAA certified run-time library and are you familiar with the requirements expected from clock APIs in such environments? I get the impression that you could learn a *lot* from building "an API in the sky" ... http://www.cl.cam.ac.uk/~mgk25/c-time/ Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>