On Wed, Dec 19, 2012 at 11:00:06AM +0000, Poul-Henning Kamp wrote:
> --------
> In message <50d192e8.3020...@freebsd.org>, Alexander Motin writes:
> >Linux uses 32.32 format in their eventtimers code.
> (And that is no accident, I know who they got the number from :-)
> >But if at some point we want to be able to
> >handle absolute wall time, [...]
> Then you have other problems, including but not limited to clock
> being stepped, leap-seconds, suspend/resume and frequency stability.
> If you want to support callouts of the type ("At 14:00 UTC tomorrow")
> (disregarding the time-zone issue), you need to catch all significant
> changes to our UTC estimate and recalibrate your callout based on
> that.
> It is not obvious that we have applications for such an API that
> warrant the complexity.
> Either way, such a facility should be layered on top of the callout
> facility, which should always run in "elapsed time"[1] with no attention
> paid to what NTPD might do to the UTC estimate.
POSIX specifies functions that assume such a facility exists, although
applications may not care much if we implement them incorrectly.
For example, pthread_mutex_timedlock() and sem_timedwait() shall time
out when the CLOCK_REALTIME clock reaches the given value, and
pthread_cond_timedwait() and clock_nanosleep() (with TIMER_ABSTIME)
shall time out when the specified clock reaches the given value.
> So summary: 32.32 is the right format.
> Poul-Henning
> [1] Notice that "elapsed time" needs a firm definition with respect
> to suspend/resume, and that this decision has big implications
> for the API use and code duplication.
> I think it prudent to specify a flag to callouts, to tell what
> should happen on suspend/resume, something like:
> SR_CANCEL /* Cancel the callout on S/R */
> /* no flag* /* Toll this callout only when system is running */
> SR_IGNORE /* Toll suspended time from callout */
> If you get this right, callouts from device drivers will just "DTRT",
> if you get it wrong, all device drivers will need boilerplate code
> to handle S/R
Userland could get access to this via CLOCK_REALTIME vs CLOCK_MONOTONIC
vs CLOCK_UPTIME.
--
Jilles Tjoelker
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
