aboutsummaryrefslogtreecommitdiff
path: root/src/or/circuitlist.h
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2013-06-16 09:55:44 -0400
committerNick Mathewson <nickm@torproject.org>2013-06-18 10:15:16 -0400
commit2e1fe1fcf93c2a77805048bea5c535ca4456d583 (patch)
tree6a396bc09f558b9611282de2d54a7f7824696095 /src/or/circuitlist.h
parent2a95f3171681ee53c97ccba9d80f4454b462aaa7 (diff)
downloadtor-2e1fe1fcf93c2a77805048bea5c535ca4456d583.tar
tor-2e1fe1fcf93c2a77805048bea5c535ca4456d583.tar.gz
Implement a real OOM-killer for too-long circuit queues.
This implements "algorithm 1" from my discussion of bug #9072: on OOM, find the circuits with the longest queues, and kill them. It's also a fix for #9063 -- without the side-effects of bug #9072. The memory bounds aren't perfect here, and you need to be sure to allow some slack for the rest of Tor's usage. This isn't a perfect fix; the rest of the solutions I describe on codeable.
Diffstat (limited to 'src/or/circuitlist.h')
-rw-r--r--src/or/circuitlist.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/or/circuitlist.h b/src/or/circuitlist.h
index 6e7735476..44f0c1fe3 100644
--- a/src/or/circuitlist.h
+++ b/src/or/circuitlist.h
@@ -57,6 +57,7 @@ int circuit_count_pending_on_or_conn(or_connection_t *or_conn);
void assert_cpath_layer_ok(const crypt_path_t *cp);
void assert_circuit_ok(const circuit_t *c);
void circuit_free_all(void);
+void circuits_handle_oom(size_t current_allocation);
#endif