New "timeout" api, to replace callout

[Poul-Henning Kamp]

In message <20071202.093603.228972203.imp at bsdimp.com>, "M. Warner Losh" writes:
>In message: <19827.1196612123 at critter.freebsd.dk>
>            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>: In message <20071202.085545.177225588.imp at bsdimp.com>, "M. Warner Losh" writes:
>: 
>: >There are a number of places in the tree that use a parameter of '1'
>: >today to mean "next time that's convenient."  Some of these places are
>: >clever and know that HZ is never < 100 or > 1000 (or so they think),
>: >while others are just sloppy code.
>: 
>: Yes, but those can hardly be called "concrete" in terms of wanting
>: to know what they mean, can they ? :-)
>: 
>: The only way I can see we can deal with them in the short term,
>: is to ask for timeouts of "1000000 / hz, TIMEOUT_USEC"
>
>Or have a "timeout_soon" function like you have the other timeout
>conversion routines.

I'm not very keen on offering too much rope.

Intelligent decisions need to be made about these polling rates and
making it too easy to not think about it would be to encourage
bad practices.


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