On 28 October 2017 at 04:52, Paul Wouters <[email protected]> wrote: > On Fri, 27 Oct 2017, Andrew Cagney wrote: > > I noticed that the timestamp added to log files has only a 1 second >> resolution; this isn't much help when multiple >> events get processed per second. The reason is a combination time() (1 >> second resolution) and strftime() (doesn't >> do sub-second resolution anyway). I suspect all this pre-dates git >> history. >> > > Yes. > > Anyway, I'm looking at an alternative. My thought is a combination of >> gettimeofday() or >> event_base_gettimeofday_cached() (the latter would peg our times to when >> the event fired I believe which may not >> be such a good idea, otoh it is cheap) and strftime() + printf(). Any >> thoughts. >> > > No specific advise from me here. Antony might know more about libevent > and using it for timers? > > I've pushed the first change.
struct timeval's getimeofday(2) claims that POSIX recommends struct timespec's clock_gettime(2). However, libevent uses struct timeval and struct timespec lacks anything like timeradd(3) et.al. so I went with the former. I think, because event_base_gettimeofday_cached() doesn't change, it would make for confusing logs. PS: I'm also left wondering why delta time isn't a double, would make >> specifying sub-second timers a lot easier >> (i.e., 0.5) >> > > I'm mostly left with a feeling time is overengineered and overly complex > in our code - even if it is theorectically the most correct :P > >> >> Once some code was cleaned up, changing realtime_t's implementation was straight forward so that does seem to work. However, deltatime_t seems to be another story. I'm going to up its precision but note that a lot of code just flips it to time_t and uses that. As for monotime_t I don't know what it is trying to do so I'll ignore it; perhaps clock_gettime(CLOCK_MONOTONIC)? Andrew
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
