Merge pull request #25 from AlteaDown/patch-1

Fixing Spelling Errors

Author: Froussios

Part 4 - Concurrency/4. Backpressure.md

@@ -22,7 +22,7 @@ Here, the producer has its values ready and can emit them with no delay. The con
 
 This works like that only for synchronous execution. It is very common for the producer and the consumer to be asynchronous. So, what happens when a producer and a consumer operate asynchronously at different speeds?
 
-Let's first consider the traditional pull-based model, such as an iterator. In a pull-based model, the consumer requests the values. If the producer is slower, the consumer will block on request and resume when the next value arrives. If the procuder is faster, then the producer will have idle time waiting for the consumer to request the next value.
+Let's first consider the traditional pull-based model, such as an iterator. In a pull-based model, the consumer requests the values. If the producer is slower, the consumer will block on request and resume when the next value arrives. If the producer is faster, then the producer will have idle time waiting for the consumer to request the next value.
 
 Rx push-based, not pull-based. In Rx, it is the producer that pushes values to the consumer when the values are ready. If the producer is slower, then the consumer will have idle time waiting for the next value to arrive. If the producer is faster, without any provisions, it will keep force-feeding data to consumer without ever knowing about the consumer's difficulties.
 
@@ -78,7 +78,7 @@ Observable.interval(1, TimeUnit.MILLISECONDS)
 ```
 
 The are similar operators that can serve the same purpose.
-* The [throttle](/Part 3 - Taming the sequence/5. Time-shifted sequences.md#throttling) family of operators also filters on rate, but allows you to speficy in a diffent way which element to let through when stressed.
+* The [throttle](/Part 3 - Taming the sequence/5. Time-shifted sequences.md#throttling) family of operators also filters on rate, but allows you to specify in a different way which element to let through when stressed.
 * [Debounce](/Part 3 - Taming the sequence/5. Time-shifted sequences.md#debouncing) does not cut the rate to a fixed maximum. Instead, it will completely remove every burst of information and replace it with a single value.
 
 #### Collect
@@ -266,7 +266,7 @@ Requested 90
 Requested 90
 ```
 
-The `zip` operator starts by requesting enough items to fill its buffer, and requests more when it consumes them. The details of how many items `zip` requests isn't interesting. What the reader should take away is the realisation that some buffering and backpressure exist in Rx whether the developer requests for it or not. This gives an Rx pipeline some flexibility, where you might expect none. It might trick you into thinking that your code is solid, by silently saving small tests from failing, but you're not safe until you have explicitly declared behaviour with regard to backpressure.
+The `zip` operator starts by requesting enough items to fill its buffer, and requests more when it consumes them. The details of how many items `zip` requests isn't interesting. What the reader should take away is the realization that some buffering and backpressure exist in Rx whether the developer requests for it or not. This gives an Rx pipeline some flexibility, where you might expect none. It might trick you into thinking that your code is solid, by silently saving small tests from failing, but you're not safe until you have explicitly declared behaviour with regard to backpressure.
 
 
 ## Backpressure policies
@@ -348,7 +348,7 @@ Observable.interval(1, TimeUnit.MILLISECONDS)
 ...
 ```
 
-What we see here is that the first 128 items where consumed normally, but then we jumped forward. The items inbetween were dropped by `onBackPressureDrop`. Even though we did not request it, the first 128 items were still buffered, since `observeOn` uses a small buffer between switching threads.
+What we see here is that the first 128 items where consumed normally, but then we jumped forward. The items in-between were dropped by `onBackPressureDrop`. Even though we did not request it, the first 128 items were still buffered, since `observeOn` uses a small buffer between switching threads.
 
 
 | Previous | Next |