Skip to content

Commit

Permalink
Fixing Spelling Errors
Browse files Browse the repository at this point in the history
  • Loading branch information
AlteaDown committed Sep 6, 2016
1 parent 46f0006 commit 4c5548d
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions Part 4 - Concurrency/4. Backpressure.md
Expand Up @@ -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.

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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 |
Expand Down

0 comments on commit 4c5548d

Please sign in to comment.