[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3199 [Tor]: Refactor periodic events
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs