[tor-bugs] #3199 [Tor]: Refactor periodic events

[Tor Bug Tracker & Wiki]

#3199: Refactor periodic events
------------------------+------------------------------
     Reporter:  nickm   |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: unspecified
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  easy tor-relay
Actual Points:          |  Parent ID:
       Points:          |
------------------------+------------------------------

Comment (by Ry):

 https://github.com/Ryman/tor/commits/bug3199

 Each ported function is a commit in this branch (with minor exception),
 you might want to use 'Log [GENERAL] info notice' to see what's happening.

 Currently, I'm accounting for the off by one errors and the delayed start
 as it's easier to test. Got some really dumb tests that will hard exit if
 they don't get an expected time (either now or the last expected time, to
 account for the one_second being run before or after the other events).
 The test macros are bad bad bad, but they'll be removed so it's not really
 a big deal I think.

 I've run most of the ports overnight without failure, but it would be good
 to have a relay running the branch for a good period of time to ensure
 it's legit and so people can feel better about it. (I can't currently run
 a relay or bridge to test due to 3g internet)

 All the static time_t's that are in run_scheduled_events are ported,
 there's still further work that might be doable once the dead code is
 removed. The dead code can be removed after it's seen to have expected
 behaviour over time.

 Once the dead code is removed then we can remove the off by one errors (as
 the hard tests will be gone) and also break up the per second callbacks
 into better chunks (and port the second_timer to get rid of redundant
 initialisation code).

 There are a lot of callbacks that get called per second due to
 precondition failures (e.g. not being a server), we can probably handle
 this better going forward. Atm, a -1 return just means poll me again next
 second and to indicate no action was taken, but we could easily have
 certain signals setup to negative return values, e.g. -7 means run me
 again when server_mode(options) changes, or even poll me again in 7
 seconds but don't mark action as having taken. This should be pretty
 simple to do in future, it's just a matter of implementing it without
 bugs! :D

 Also, I haven't really made these timers accessible/first-class yet, I
 couldn't figure out an especially clean way to do it without having to
 edit two points per code change, but it should be easy enough to do.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3199#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online