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

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Sat, 22 Dec 2012 22:57:54 +0000
--------
In message <20121222225025.GA46583_at_stack.nl>, Jilles Tjoelker writes:

>> 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.

It should still be implemented op top of callouts, not as part of:
it is an entirely different thing to try to do right.

>> 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.

I have _no_ idea what you are trying to say here...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Sat Dec 22 2012 - 21:58:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC