Re: API explosion (Re: [RFC/RFT] calloutng)

On Wed, Dec 19, 2012 at 11:00:06AM +0000, Poul-Henning Kamp wrote:
> --------
> In message <50D192E8.3020704_at_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