Messages in this thread | | | Subject | Re: [patch 00/43] ktimer reworked | Date | Sat, 3 Dec 2005 20:28:57 -0500 | From | Andrew James Wade <> |
| |
On Thursday 01 December 2005 14:08, Steven Rostedt wrote: > On Thu, 2005-12-01 at 18:44 +0100, Roman Zippel wrote: > > Hi, > > > > On Thu, 1 Dec 2005, Russell King wrote: > ... > > > Hence, timers have the implication that they are _expected_ to expire. > > > Timeouts have the implication that their expiry is an exceptional > > > condition. > > > > IOW a timeout uses a timer to implement an exceptional condition after a > > period of time expires. > > > > > So can we stop rehashing this stupid discussion? > > > > The naming isn't actually my primary concern. I want a precise definition > > of the expected behaviour and usage of the old and new timer system. If I > > had this, it would be far easier to choose a proper name. > > E.g. I still don't know why ktimeout should be restricted to raise just > > "error conditions", as the name implies. > > > > ktimeout may not need to be restricted to anything.
But does it make sense to use it in any other circumstances? It sounds like the rb-tree based ktimer system is suitable for the general case. So you can have a simple rule: use ktimeout for timing out when an expected event doesn't occur, and ktimer for everything else. Are there any situations where you want a timer optimized for the removal case that is not also monotonic and low-res? And are there any situations in practice other than the "timeout" one where you'd want to use a timer wheel instead of a rb-tree?
It sounds to me that the ktimer should be the general case, leaving ktimeout to be optimized for one particular case (by e.g. decreasing the resolution to reduce cascades).
Andrew Wade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |