blob: ca06d3286fb8a79ab8db058b64587e906467879c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
//f.barrier(auth).barrier(ratelimit).and_then(|result| {})
//A ratelimiter must be aware when a limit is hit, the upper limit,
//and remaining requests. (use case specific)
//
//This can be done by either letting the ratelimiter drive the request
//so it can inspect returned headers or by maybe? using a channel to inform
//the limiter
//
//Submit task to ratelimiter.
//Check if the limit is hit and if we are polling
// 1 if we hit the limit and are not polling, add to the queue and start
// polling.
// 2. if we are polling add the request to the queue
// 3. if we are not polling and not locked then
// send the request and increment the in-flight counter.
//
// when the request has completed without errors then decrement
// the in-flight counter, update limiter data, and return the
// result to the requester.
//
// On error, EITHER:
// 1. If the error is rate limiter related place the request
// back in a queue, return other errors. (Prevents starvation)
// 2. Return all errors back to the Requester they can resubmit
// the request
//
// The main difference is that the condition is dependent on the waiter's
// future result.
//
// For auth requests we can use an OkFuture that returns the waiter and never errs
//
// So waiters must provide IntoFuture, a future than can poll the condition,
// and a is locked.
// The lock check must be pure (no side effects) but IntoFuture may
// have side effects (eg. increments in-flight counter)
//
// The result of the IntoFuture is returned to caller or the Err of the poll
// Future. For simplicity these will be the same type.
//
// Should the poll condition trait be located on the Waiter or the Barrier?
// All waiters in a barrier must use the same condition.
pub mod barrier;
pub mod waiter;
|
