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>
This commit is contained in:
Micah Elizabeth Scott 2023-04-11 10:28:09 -07:00
parent 6023153631
commit a13d7bd5e9

View File

@ -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,12 +829,8 @@ 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;
}
}
/* If there are still some pending rendezvous circuits in the pqueue then
* reschedule the event in order to continue handling them. */