Date: Wed, 29 Nov 2006 23:48:11 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@phk.freebsd.dk Cc: rwatson@freebsd.org, freebsd-arch@freebsd.org Subject: Re: a proposed callout API Message-ID: <20061129.234811.-1625879484.imp@bsdimp.com> In-Reply-To: <11587.1164837604@critter.freebsd.dk> References: <200611291650.51782.jhb@freebsd.org> <11587.1164837604@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <11587.1164837604@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: In message <200611291650.51782.jhb@freebsd.org>, John Baldwin writes:
:
: >> I want it marked up directly in the flags passed which kind of behaviour
: >> the code wants.
: >
: >Hmm, I guess that depends on what you consider tick_t to be. I was thinking
: >of it as an abstract type for a deadline, and that absolute and relative are
: >sort of like subclasses of that.
:
: I see tick_t only as an opaque measure of time and would prefer to
: not have modal bits stuck into it because I fear that will make it
: larger than 32 bits.
There's many times and places that confuse a time interval with an
elapsed time since an epoch. struct timeval started life as the
latter and was press-ganged to also surve as the former. Having
different types allows for an unabiguous conversion. I don't believe
there's a prohibitive cost in doing this.
I'd also argue that UTC is just a printing convention anyway. Keeping
time in a TAI-like timescale and doing the conversion to UTC when UTC
timestamps are necessary would be worth considering, but there are
some costs with doing this that might prove to be too high since UTC
is used a lot and any TAI-like thing is only used for the 'core'
timing stuff.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061129.234811.-1625879484.imp>