Date: Sun, 02 Dec 2007 15:58:58 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: New "timeout" api, to replace callout Message-ID: <19722.1196611138@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 02 Dec 2007 08:46:48 MST." <20071202.084648.-108809549.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20071202.084648.-108809549.imp@bsdimp.com>, "M. Warner Losh" writes
:
>In message: <15391.1196547545@critter.freebsd.dk>
> Poul-Henning Kamp <phk@phk.freebsd.dk> writes:
>>>/*
>>> * A duration of time, represented in the optimal way for a given provider
>>> * or family of providers (ie: per cpu).
>>> */
>>>typedef int timeout_time;
>
>What does this mean? How do I get one of those? Without a unit
>associated with this number, it becomes hard to do a "tickless"
>implementation.
You get it back from the timeout provider. The point here is that
most timeout clients use the same time interval again and again,
so precalculating any "magic" values for the specific hardware makes
sense.
In practice your code could look like:
struct foo_softc {
timeout_time timeout_duration;
};
...
foo_attach() {
[...]
sc->timeout_duration = timeout_conv_time([...], 200, TIMEOUT_MSEC);
}
foo_something() {
timeout_arm(sc->timeout, sc->timeout_duration, [flags]);
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19722.1196611138>