Messages in this thread | | | Date | Mon, 17 Oct 2005 22:09:49 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5 |
| |
* Roman Zippel <zippel@linux-m68k.org> wrote:
> > > It's rather simple: > > > - "timer API" vs "timeout API": I got absolutely no acknowlegement that this > > > might be a little confusing and in consequence "process timer" may be a > > > better name. > > > > I agree with Thomas on this one. Maybe "timer" and "timeout" are too close, > > but I think they are the most descriptive names. > > - timeout is something used for a timeout. Timeouts only actually > > expire infrequently, so they have a host of attributes associated > > with that characteristic. > > - timer is something used to time something. They almost always > > expire as part of their normal behaviour. In the ktimer code they > > have a host of attributes related to this characteristic. > > There is of course a difference, but is it big enough that they > deserve different APIs? Just look into <linux/timer.h> it doesn't > mention timeout once, but according to Thomas that's our "timeout > API". Look at the description of mod_timer() in timer.c: "modify a > timer's timeout". It seems I'm not only one who thinks that both are > closely related.
this is one more area where there's no good substitute from 'walking the walk', i.e. getting yourself dirty with actual code. I have been involved with the following variants which were part of the -rt tree:
- we implemented both timeouts and timers with the same timeout-optimized framework [i.e. with the 'wheel'] - it sucked.
- timers and timeouts with a timer-optimized framework [i.e. with a binary tree] sucks too, due to the tree overhead.
- we in fact tried another variant too: a hybrid method where timers and timeouts lived in the timer wheel and some time before (hr) timers were about to time out they were put into a separate hr-list. This hybrid solution sucked too.
so then we tried a separate API and subsystem for both of them, and voila, many of the uglinesses went away, and things became robust.
Ingo - 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/
| |