Junio C Hamano <gits...@pobox.com> writes: > Junio C Hamano <gits...@pobox.com> writes: > >> I think the goal to have our own stopwatch so that we do not have to >> worry about differences among system-provided ones makes sense. >> >> The only thing that may become an issue is how widely available >> getnanotime() is. As "test-date" itself is built on any platform an >> end-user/developer runs our tests, which is wider set of platforms >> than what we run Travis and other CIs on, unconditionally relying on >> its availability might pose an issue. > > Sorry for a false alarm, as the codebase in many places like > fsmonitor, progress, trace and wt-status have been assuming > getnanotime() to be available for quite some time, and this is just > another user of the same function.
And there was yet another misunderstanding on my part. I thought that the mention of getnanotime() was about https://www.freebsd.org/cgi/man.cgi?query=getnanotime&sektion=9 and I did not realize that the hits I saw in "git grep getnanotime" were referring to an unrelated function trace.c::getnanotime() of our own. Of course, it is safe to use that function in the tests ;-) Again, sorry for the false alarm. We _might_ get a complaint from freebsd devs when they want to use their getnanotime(9) to implement highres_nanos(), and the cleanest solution to that complaint will be to rename our own getnanotime() to git_nanotime() or something, but (1) that is totally outside the scope of this series that adds one more caller to the function and (2) we can do that when we actually get such a complaint.
