[Swan-dev] new delta time type

[D. Hugh Redelmeier]

| From: Antony Antony <antony at phenome.org>
| To: D. Hugh Redelmeier <hugh at mimosa.com>
| Cc: Libreswan Development List <swan-dev at lists.libreswan.org>
| Date: Fri, 23 Jan 2015 12:59:52 -0800
| Subject: Re: [Swan-dev] new delta time type
| 
| The reason I didn't use timeval immediately in #libevent was due to lack 
| of arithmetic and configuration option parsing functions. Otherwise 
| timeval seems an obvious choice except when defining constants.

In the user-visible interface, everything up to now has been in
seconds.  The natural way to extend the interface is in terms of
seconds with decimal fractions.  I'm not saying that this should be
the internal representation.

I don't think that it is too hard to write our own code to do
arithmetic on struct timeval given that we need to do so little
arithmetic.

If I tried, I might be surprised.

The representation in libipsecconf should probably be a string, just
to get around the floating point mess.  Conversion from string to
internal rep should appear one place for settings coming
through whack and through conf file.

In any case, I will argue elsewhere that these settings should be
experimental at the moment, so a polished user interface may not be
urgent.

Alternative hack suggestion: time-valued parameters can have a suffix
to specify the units.  Maybe we need one (non-default) to specify
milliseconds or microseconds (u?).  That could stave off the
requirement for decimal fractions (still the best way for humans, I
think).  Not perfect, just better than bare integers meaning
different times in different contexts.

| If we create a type it could be called delta_tv. I guess the 
| configuration parser should understand this and store the value in 
| delta_tv. arithmetic functions and parsing functions looks like a major 
| surgery:)

I've done just enough with the config file parser that I think that it
isn't too hard to hack.

| If we use timeval, can we use something like 
| http://www.geonius.com/software/libgpl/tv_util.html ;  If the license 
| compatible with libreswan?

Looks plausible.  But I don't think our own code would be very
complex.

| A consideration is mixing timeval with existing enum we have, such as 
| secs_per_day, secs_per_minute. I am not sure how to define constants for 
| struct timeval. If that also needs update it could quickly become a lot 
| of work. Float and int are most friendly to define constants.

If we want to be fully general, I guess all times should be
represented in wrapped struct timevals.  I say "wrapped" because I
want C to see them as separate types to protect us from mistakes.

This is perhaps the best way to go.

Since our old time types are wrapped already, this shouldn't be to
hard.

Of course this is overkill, but I'm not sure that the costs are
significant.

| One thought that is crossing my mind is why not use a float? We don't 
| want epoch, just delta timeval. So it could fit into float? Then 
| arithmetic and formatting become easier. Still there could be a need for 
| timeval to float and float to timeval conversion functions.

Float has some appeal, for sure.  But I hate floating point.  It has a
lot of non-intuitive failure modes.

In the old days, I'd use the excuse that using any floating point adds
overhead not worth paying.  For example, the Linux kernel doesn't use
floating point.  But that argument is getting obsolete.

| > microseconds.  (Using "ms" in various names feels a little too specific.)
| 
| How do you suggest we format the string? Until now it is only used in debug log

Yeah.  It's slightly tricky.  I think that I fixed that formatting.
With my fix, the problem is dealt with, but with a lot of trailing
zero digits.

Part of the problem is that I don't understand the use cases
completely.  For example, I don't think that we need to specify
timeouts with microsecond precision so they don't need to be reported
to that precision.

I was suggesting struct timeval because we already need to use that
representation.