Implement monotonic time in a better way than simply calling down to libevent's non-monotonic time

For a synopsis of the various better ways, see what libevent 2.1 will someday do, in https://github.com/libevent/libevent/blob/master/evutil_time.c#L137 .

changed milestone to %Tor: 0.2.9.x-final

added TorCoreTeam201607 actualpoints::1 component::core tor/tor milestone::Tor: 0.2.9.x-final owner::nickm points::1 priority::medium resolution::fixed review-group-5 severity::normal status::closed type::enhancement labels

Trac:
Points: N/A to small

Marking these tickets as the ones I think I need more feedback about in order to figure out if I think it should go in 0.2.9.

Trac:
Keywords: N/A deleted, 029-nickm-unsure added

Calling these "yes for 0.2.9" since a good implementation of mike's padding patches requires them.

Trac:
Milestone: N/A to Tor: 0.2.9.x-final

Trac:
Keywords: 029-nickm-unsure, 029-proposed. deleted, N/A added

Trac:
Points: small to 1

I've started this in a branch monotonic_v2. More work is needed: I need to test it and finish the windows code.

Trac:
Owner: N/A to nickm
Status: new to accepted

Trac:
Keywords: N/A deleted, review-group-5 added

Trac:
Reviewer: N/A to athena

Now with unit tests and a changes file

Trac:
Actualpoints: N/A to 1
Status: accepted to needs_review

Begin code review for nickm/monotonic_v2:

Summary: I think I'm good with this being merged as long as all four cases (clock_gettime(), gettimeofday(), Windows and Mac OS) got tested.

aa971c59246332391116caafd18855bccf2f99a5:

• Just moving code here. Looks good to me.

e42e054fbfb5dd8d4a5729f9f7988b2def60840e:

• Good, this doesn't make any particular assumptions about the origin of monotonic time. On current Linux, CLOCK_MONOTONIC is actually since system boot. The parts for platforms I know look okay to me, but did we manage to actually test the Windows / Mac OS X stuff?

  (cf. e431ed37360a405f36e07a8c902146f0b4f4b31b)

a2e5704a912ba06255c56de5603fce6444ebad98:

• Looks fine.

4baf1d04db6c8e84a113cc801284be3dbe23884e:

• Looks okay.

e431ed37360a405f36e07a8c902146f0b4f4b31b:

• Hmm, looks okay but have we tested it on Windows yet?

8edc842182df6c2036e51d5e4c3de6248f3065f9:

• Just test suite exposure.

1e21947464f81fb55e6f6ce52c43244933ef6657:

• Okay, it compiles but have we tested it? :P

cb45ee9494c93064ba61f6503aa9abfd583555db:

• Woot, a pure code deletion commit

81ca7a984a5a7820a5af5b9f1ad1f59d8c0ebc7f:

• Looks fine.

49ec146a3c7876c03040fefcab6345146d3b9ef3:

• Unit tests only in this one; they look fine.

8f0ba05a2522c56eebb8d239c5a3f431e88a7261:

• Just the changes file

End code review

Your main questions were about testing. I ran the tests on Linux, OSX, and on Linux with clock_gettime artificially disabled. They all seemed to work okay. I compiled the windows tests, but didn't have an easy way to run them. I think I'll just merge, though, and see what Jenkins thinks? Unless you object.

Trac:
Status: needs_review to merge_ready

Yeah, I think I'm happy with that.

Okay. Squashed and merged.

Trac:
Resolution: N/A to fixed
Status: merge_ready to closed

Trac:
Keywords: review-group-5 deleted, review-group-5 TorCoreTeam201607 added

closed

changed time estimate to 8h

added 8h of time spent

mentioned in issue #18909 (moved)