#113 Add an interface for cached monotonic time
This patch adds three new functions to event.c:
1. int event_base_gettimeofday_cached_ts(struct event_base *base, struct timespec *ts)
This is a timespec-based version of event_base_gettimeofday_cached() for developers whose code is timespec-based and wish to use the cached time-of-day clock without having to convert from timevals.
2. int event_base_gettime_monotonic_cached(struct event_base *base, struct timeval *tv)
This function is the same as event_base_gettimeofday_cached() except that it returns the cached monotonic time, if available.
3. int event_base_gettime_monotonic_cached_ts(struct event_base *base, struct timespec *ts)
This is a timespec-based version of event_base_gettime_monotonic_cached()
I've also modified configure.ac and until.h so that the timespec equivalents to commonly used timeval macros are available if needed. I added timespec=>timeval and timeval=>timespec conversion macros as well. test/regress_util.c has been modified to test changes to evutil_time.c:evutil_gettime_monotonic_(). I added a new unit-test test-cached.c to test all the cached timestamp functions, and modified the scripts and makefile templates accordingly.
git diff against 2.1 alpha
Hi! Thanks for the patch. Here are some quick initial thoughts.
1) Shouldn't there be an autoconf test for whether struct timespec is defined at all? I think that windows doesn't have it, for example, and I'm pretty sure that some older unixes don't have it either.
2) Must we derive ts_clock_diff.tv_nsec from tv_clock_diff.tv_usec ? Couldn't we do it the other way around somehow, computing a nanosecond skew and then using it to establish the microsecond skew? That seems like it would be more accorate.
3) The implementation of event_base_gettimeofday_cached_ts seems iffy; it should be trying to base everything off of the monotonic clock plus a skew whenever possible, and never actually call gettimeofday. (Rationale: Anybody who calls the version returning 'struct timespec' probably wants sub-microsecond accuracy.)
4) Actually, I'm a little confused about cached time on the nanosecond level. Why would you want that? In other words, if you need sub-microsecond resolution, would you really be satisfied with a cached value? (I can take a "yes" for an answer here, but it would be good to have some idea why.)
other than those, it seems okay at first glance. I haven't read the test code carefully though.
Hi Nick, thanks for the prompt response. See my comments below.
1. I agree. I will look into this, and include a declaration for "struct timespec" if it is not available.
2 & 3. I think I can address both of these issues by adding an interface to evutil_time.c that gets the time of day in a timespec. Using this interface will allow deriving the tv_clock_diff from the ts_clock_diff as you suggest, and avoid calling gettimeofday() in event_base_gettimeofday_cached_ts(). I had actually considered doing this, but decided instead to try & minimize the number of changes I was making. But since you asked.... :-)
4. We don't really need nsec resolution in the cached timer. What we need is compatibility with the rest of our code, which uses clock_gettime() instead of the deprecated gettimeofday(). The code that uses the cached timer is performance-critical so we want to avoid having to convert back & forth between timevals & timespecs.