This is an automated email from the git hooks/post-receive script.
dgoulet pushed a commit to branch main in repository tor.
commit a13d7bd5e96765ac7c660415a498d9d9100ade62 Author: Micah Elizabeth Scott beth@torproject.org AuthorDate: Tue Apr 11 10:28:09 2023 -0700
hs_pow: always give other events a chance to run between rend requests
This dequeue path has been through a few revisions by now, first limiting us to a fixed number per event loop callback, then an additional limit based on a token bucket, then the current version which has only the token bucket.
The thinking behing processing multiple requests per callback was to optimize our usage of libevent, but in effect this creates a prioritization problem. I think even a small fixed limit would be less reliable than just backing out this optimization and always allowing other callbacks to interrupt us in-between dequeues.
With this patch I'm seeing much smoother queueing behavior when I add artificial delays to the main thread in testing.
Signed-off-by: Micah Elizabeth Scott beth@torproject.org --- src/feature/hs/hs_circuit.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/feature/hs/hs_circuit.c b/src/feature/hs/hs_circuit.c index c3f2fbfc1e..ccd6711041 100644 --- a/src/feature/hs/hs_circuit.c +++ b/src/feature/hs/hs_circuit.c @@ -767,7 +767,9 @@ handle_rend_pqueue_cb(mainloop_event_t *ev, void *arg) in_flight, smartlist_len(pow_state->rend_request_pqueue));
- /* Process rendezvous request until the maximum per mainloop run. */ + /* Process only one rend request per callback, so that this work will not + * be prioritized over other event loop callbacks. We may need to retry + * in order to find one request that's still viable. */ while (smartlist_len(pow_state->rend_request_pqueue) > 0) {
/* first, peek at the top result to see if we want to pop it */ @@ -827,11 +829,7 @@ handle_rend_pqueue_cb(mainloop_event_t *ev, void *arg)
++pow_state->rend_handled; ++in_flight; - - if (pow_state->using_pqueue_bucket && - token_bucket_ctr_get(&pow_state->pqueue_bucket) < 1) { - break; - } + break; }
/* If there are still some pending rendezvous circuits in the pqueue then