Re: [libgpiod] cxx bindings: time_point vs duration

[Jack Winch <sunt.un.morcov@xxxxxxxxx>]

> You're arguing that a std::chrono::steady_clock::time_point is not a good match due to its undefined ratio.

std::chrono::steady_clock::time_point is not a good match for the
reasons you have quoted.

> That can be fixed by using a clock with a well-defined ratio.

I agree that defining a clock with a suitable ratio would remove the
problems faced when using a clock with an undefined ratio.

> The key here is that while you can easily convert your duration to a
> time_point, a duration is conceptually the wrong thing to use.

I agree that the timestamp value is conceptually a time_point.

> If you are not satisfied with the resolution
> guarantuee of steady_clock, just make your own clock. Doing so results
> in a lot of type safety. For instance, if you accidentally compute a
> difference between a system_clock::time_point and a gpiod timestamp,
> using a duration would just work whereas a time_point would result in a
> compilation failure.

I also agree with the excellent point you raise regarding type safety
and preferring compile-time errors to runtime errors.  Where possible,
care should be taken to mitigate or eradicate the potential for these
types of runtime bug.

The problem is, the solution you were suggesting to be suitable was
not (in its current form).  There are numerous issues with the
proposal above, which require further discussion.  As has been pointed
out, changes were made to the char dev in Linux 5.7 such that line
events are timestamped using the system 'monotonic' clock as opposed
to the 'realtime' clock.  So now the clock in which that timestamp is
relative to is kernel version dependent.  The ability to configure
this will become available in the next version of the kernel, but the
problem of which system clock is being used for older kernels will
still remain.

I rebuffed the suggestion in the manner that I did as the change would
have caused issues.  I completely understand and agree with the key
rationale behind the proposed change.  With further discussion, a
suitable solution might be found, but it requires further thought.
What I did not want to see happen is the change as currently proposed
be applied and cause issues in the future.

That being said, let's continue this discussion to see what can be
done (and preferably without any p*ssing contest).  The remainder of
this week is no good for me, but would you be available to discuss
potential solutions next week, Helmut?

Jack