Timer library

Fabien Tassin fta at sofaraway.org
Mon Feb 5 10:05:27 UTC 2001

According to Alex Kiernan:
> > 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.

it is possible to use nested timers ?
It is the reason I've created the history timer... it is sometimes
interesting to have reports of nested functions as a tree like the one
I've shown as a sample of "stathist".

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

unified or contextual patches sent to inn-patches at isc.org are usually fine.
If you Cc inn-workers, be careful, Listar doesn't like non ASCII attachments.

Fabien Tassin -+- fta at sofaraway.org

More information about the inn-workers mailing list