Timer library

[Alex Kiernan]

Russ Allbery <rra at stanford.edu> writes:

> Alex Kiernan <alexk at demon.net> writes:
> 
> > I've got most of the history code hauled out into a separate library
> > (still got expire to do), but I'm trying to figure the best approach to
> > dealing with the timers in it.
> 
> > I'm inclined to move timer.c into libinn & merge the timers from
> > innfeed, so that there's one place where timers happen, and you just get
> > some of them permanently zero in an application when you're not using
> > those bits.
> 
> > Thoughts?
> 
> Please!  I was going to do this myself, but I'll be quite happy to have
> you beat me to it.
> 
> One approach to consider that I was thinking about doing:  Have the
> library only track timers by number and then have the calling application
> pass in an array of number to name mappings for the periodic logging.
> That way you can put the enum and the number to string array in the client
> and the timer code can be completely generic and won't have to be modified
> every time we add timing to another program and want more timer types.
> 

OK, that makes sense. I've given the library code the first n elements
(depending on what's in the enum) so that things like history routines
in the libary can be timed, you then start your application numbering
at n+1 and pass N to the TMRinit routine. Per-application strings get
passed into summarise & it has the library strings hard coded.

What's the best way to pass this stuff to you for committing? I'm
rapidly approaching the point where its hard to separate out the
different pieces...

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC