summaryrefslogtreecommitdiff
path: root/src/or/circuituse.h
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2013-02-19 18:29:17 -0500
committerNick Mathewson <nickm@torproject.org>2013-02-19 18:29:17 -0500
commit62fb209d837f3f5510075ef8bdb6e231ebdfa9bc (patch)
tree5cac02bf416adc7cd9c5bb3f0b219d6c6bdb966d /src/or/circuituse.h
parent337e32f5b8f5f3b310da20bf0135f17d06efb3ab (diff)
downloadtor-62fb209d837f3f5510075ef8bdb6e231ebdfa9bc.tar.gz
tor-62fb209d837f3f5510075ef8bdb6e231ebdfa9bc.zip
Stop frobbing timestamp_dirty as our sole means to mark circuits unusable
In a number of places, we decrement timestamp_dirty by MaxCircuitDirtiness in order to mark a stream as "unusable for any new connections. This pattern sucks for a few reasons: * It is nonobvious. * It is error-prone: decrementing 0 can be a bad choice indeed. * It really wants to have a function. It can also introduce bugs if the system time jumps backwards, or if MaxCircuitDirtiness is increased. So in this patch, I add an unusable_for_new_conns flag to origin_circuit_t, make it get checked everywhere it should (I looked for things that tested timestamp_dirty), and add a new function to frob it. For now, the new function does still frob timestamp_dirty (after checking for underflow and whatnot), in case I missed any cases that should be checking unusable_for_new_conns. Fixes bug 6174. We first used this pattern in 516ef41ac1fd26f338c, which I think was in 0.0.2pre26 (but it could have been 0.0.2pre27).
Diffstat (limited to 'src/or/circuituse.h')
-rw-r--r--src/or/circuituse.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/or/circuituse.h b/src/or/circuituse.h
index d4d68aad92..11e5a64163 100644
--- a/src/or/circuituse.h
+++ b/src/or/circuituse.h
@@ -55,6 +55,7 @@ void circuit_change_purpose(circuit_t *circ, uint8_t new_purpose);
int hostname_in_track_host_exits(const or_options_t *options,
const char *address);
+void mark_circuit_unusable_for_new_conns(origin_circuit_t *circ);
#endif