mirror of
https://github.com/tower-rs/tower.git
synced 2025-09-28 05:20:57 +00:00
chore: fix spelling errors (#775)
Co-authored-by: Dirk Stolle <striezel-dev@web.de>
This commit is contained in:
parent
89ac74f320
commit
74e925d2c8
@ -390,7 +390,7 @@ means we can combine multiple errors type into one. That has the following
|
||||
advantages:
|
||||
|
||||
1. Our error handling is less fragile since changing the order middleware are
|
||||
applied in wont change the final error type.
|
||||
applied in won't change the final error type.
|
||||
2. The error type now has a constant size regardless how many middleware we've
|
||||
applied.
|
||||
3. Extracting the error no longer requires a big `match` but can instead be done
|
||||
@ -412,7 +412,7 @@ For our `Timeout` middleware that means we need to create a struct that
|
||||
implements `std::error::Error` such that we can convert it into a `Box<dyn
|
||||
std::error::Error + Send + Sync>`. We also have to require that the inner
|
||||
service's error type implements `Into<Box<dyn std::error::Error + Send +
|
||||
Sync>>`. Luckily most errors automatically satisfies that so it wont require
|
||||
Sync>>`. Luckily most errors automatically satisfies that so it won't require
|
||||
users to write any additional code. We're using `Into` for the trait bound
|
||||
rather than `From` as recommend by the [standard
|
||||
library](https://doc.rust-lang.org/stable/std/convert/trait.From.html).
|
||||
@ -521,7 +521,7 @@ where
|
||||
|
||||
## Conclusion
|
||||
|
||||
Thats it! We've now successfully implemented the `Timeout` middleware as it
|
||||
That's it! We've now successfully implemented the `Timeout` middleware as it
|
||||
exists in Tower today.
|
||||
|
||||
Our final implementation is:
|
||||
|
@ -23,7 +23,7 @@
|
||||
//! Since the load balancer needs to perform _random_ choices, the constructors in this module
|
||||
//! usually come in two forms: one that uses randomness provided by the operating system, and one
|
||||
//! that lets you specify the random seed to use. Usually the former is what you'll want, though
|
||||
//! the latter may come in handy for reproducability or to reduce reliance on the operating system.
|
||||
//! the latter may come in handy for reproducibility or to reduce reliance on the operating system.
|
||||
//!
|
||||
//! [Power of Two Random Choices]: http://www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf
|
||||
//! [finagle]: https://twitter.github.io/finagle/guide/Clients.html#power-of-two-choices-p2c-least-loaded
|
||||
|
@ -31,7 +31,7 @@ use tracing::{debug, trace};
|
||||
/// in the ready set. The `ReadyCache::check_*` functions can be used to ensure
|
||||
/// that a service is ready before dispatching a request.
|
||||
///
|
||||
/// The ready set can hold services for an abitrarily long time. During this
|
||||
/// The ready set can hold services for an arbitrarily long time. During this
|
||||
/// time, the runtime may process events that invalidate that ready state (for
|
||||
/// instance, if a keepalive detects a lost connection). In such cases, callers
|
||||
/// should use [`ReadyCache::check_ready`] (or [`ReadyCache::check_ready_index`])
|
||||
|
@ -91,7 +91,7 @@ where
|
||||
///
|
||||
/// An example use case is a sharded service.
|
||||
/// It accepts new requests, then:
|
||||
/// 1. Determines, via the provided [`Picker`], which [`Service`] the request coresponds to.
|
||||
/// 1. Determines, via the provided [`Picker`], which [`Service`] the request corresponds to.
|
||||
/// 2. Waits (in [`Service::poll_ready`]) for *all* services to be ready.
|
||||
/// 3. Calls the correct [`Service`] with the request, and returns a future corresponding to the
|
||||
/// call.
|
||||
|
@ -63,7 +63,7 @@ pin_project! {
|
||||
/// reqs.unbounded_send("three").unwrap();
|
||||
/// drop(reqs);
|
||||
///
|
||||
/// // We then loop over the response Strem that we get back from call_all.
|
||||
/// // We then loop over the response `Stream` that we get back from call_all.
|
||||
/// let mut i = 0usize;
|
||||
/// while let Some(rsp) = rsps.next().await {
|
||||
/// // Each response is a Result (we could also have used TryStream::try_next)
|
||||
|
@ -27,11 +27,11 @@ pub trait Rng {
|
||||
// Borrowed from:
|
||||
// https://github.com/rust-random/rand/blob/master/src/distributions/float.rs#L106
|
||||
let float_size = std::mem::size_of::<f64>() as u32 * 8;
|
||||
let precison = 52 + 1;
|
||||
let scale = 1.0 / ((1u64 << precison) as f64);
|
||||
let precision = 52 + 1;
|
||||
let scale = 1.0 / ((1u64 << precision) as f64);
|
||||
|
||||
let value = self.next_u64();
|
||||
let value = value >> (float_size - precison);
|
||||
let value = value >> (float_size - precision);
|
||||
|
||||
scale * value as f64
|
||||
}
|
||||
@ -111,8 +111,8 @@ where
|
||||
|
||||
/// A sampler modified from the Rand implementation for use internally for the balance middleware.
|
||||
///
|
||||
/// It's an implementation of Floyd's combination algorithm. with amount fixed at 2. This uses no allocated
|
||||
/// memory and finishes in constant time (only 2 random calls)
|
||||
/// It's an implementation of Floyd's combination algorithm with amount fixed at 2. This uses no allocated
|
||||
/// memory and finishes in constant time (only 2 random calls).
|
||||
///
|
||||
/// ref: This was borrowed and modified from the following Rand implementation
|
||||
/// https://github.com/rust-random/rand/blob/b73640705d6714509f8ceccc49e8df996fa19f51/src/seq/index.rs#L375-L411
|
||||
|
Loading…
x
Reference in New Issue
Block a user