[tor-bugs] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Oct 29 00:13:17 UTC 2016

#18873: Refactor circuit_predict_and_launch_new()
 Reporter:  asn           |          Owner:
     Type:  defect        |         Status:  needs_review
 Priority:  Low           |      Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  refactoring   |  Actual Points:
Parent ID:                |         Points:
 Reviewer:  dgoulet       |        Sponsor:

Comment (by teor):

 This is an incomplete review:

 Replying to [comment:3 chelseakomlo]:
 > Second, I refactored circuit_predict_and_launch_new. This is mainly a
 refactor that improves readability/testability, but I did remove one piece
 of logic which- after writing unit tests to support this- seemed
 > The piece of logic that I removed is here:
 > As later, we exit if the circuit is not general purpose:
 > Let me know if this isn't a good idea and I can add it back in.

 In general, if you're going to change behaviour in a refactor, please put
 it in a separate commit that describes the changes. That way, you separate
 changes that are meant to keep the same behaviour, from changes that are
 meant to modify behaviour.

 In this particular case, if you're convinced it's unnecessary, I would
 prefer it if we replaced this check with a BUG macro like so:
 origin_circ = TO_ORIGIN_CIRCUIT(circ);
 if (origin_circ->unusable_for_new_conns)

 That way, we won't assert and crash in TO_ORIGIN_CIRCUIT() if the check
 turns out to be needed now, or if someone breaks that assumption in
 calling code in future.

 Also, I find `add_flags(1, 1, 1)` much less readable than `flags =

 Can we either remove the add_flags part of the refactor, or keep the flag

 > Third, I extracted some magic numbers into named variables. I am not
 sure if the naming for these is the best, please let me know ideas for
 better names.

 I don't think the name SUFFICIENT_UNUSED_OPEN_CIRCUITS captures the intent
 -    if (num < MAX_UNUSED_OPEN_CIRCUITS-2

 The comment above that explains why we subtract 2:
   /* Finally, check to see if we still need more circuits to learn
    * a good build timeout. But if we're close to our max number we
    * want, don't do another -- we want to leave a few slots open so
    * we can still build circuits preemptively as needed.

 I suggest instead:


 And then putting the defines under the existing comment.

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

More information about the tor-bugs mailing list