Merge pull request #16 from tikv/wrap80

80 characters per line is preferred

.travis.yml

@@ -0,0 +1,10 @@
+language: minimal
+
+env:
+  - IGNORE_PAT="^\[.*\]:"
+
+script:
+  - for f in text/*; do
+      grep -vE $IGNORE_PAT $f | fold -s | diff -I $IGNORE_PAT - $f ||
+        ( echo "Please wrap RFCs at 80 characters" && exit 1 );
+    done

README.md

@@ -1,10 +1,14 @@
 # TiKV RFCs
 
-Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.
+Many changes, including bug fixes and documentation improvements can be
+implemented and reviewed via the normal GitHub pull request workflow.
 
-Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the TiKV community.
+Some changes though are "substantial", and we ask that these be put through a
+bit of a design process and produce a consensus among the TiKV community.
 
-The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project, so that all stakeholders can be confident about the direction the project is evolving in.
+The "RFC" (request for comments) process is intended to provide a consistent
+and controlled path for new features to enter the project, so that all
+stakeholders can be confident about the direction the project is evolving in.
 
 ### How to submit an RFC
 
@@ -16,13 +20,20 @@ The "RFC" (request for comments) process is intended to provide a consistent and
 
 1. An RFC is submitted as a PR.
 2. Discussion takes place, and the text is revised in response.
-3. The PR is merged or closed when at least two project maintainers reach consensus.
+3. The PR is merged or closed when at least two project maintainers reach
+   consensus.
+
+### Style of an RFC
+
+We should wrap line at 80 characters.
 
 ### License
 
-This content is licensed under Apachie License, Version 2.0, ([LICENSE](LICENSE) or
-   http://www.apache.org/licenses/LICENSE-2.0)
+This content is licensed under Apachie License, Version 2.0,
+([LICENSE](LICENSE) or http://www.apache.org/licenses/LICENSE-2.0)
 
 ### Contributions
 
-Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
+Unless you explicitly state otherwise, any contribution intentionally submitted
+for inclusion in the work by you, as defined in the Apache-2.0 license, shall
+be dual licensed as above, without any additional terms or conditions.

template.md

@@ -1,10 +1,13 @@
+<!-- 80 characters per line is preferred -->
+
 # Summary
 
 One para explanation of the proposal.
 
 # Motivation
 
-Why are we doing this? What use cases does it support? What is the expected outcome?
+Why are we doing this? What use cases does it support? What is the expected
+outcome?
 
 # Detailed design
 
@@ -21,9 +24,10 @@ Why should we not do this?
 # Alternatives
 
 - Why is this design the best in the space of possible designs?
-- What other designs have been considered and what is the rationale for not choosing them?
+- What other designs have been considered and what is the rationale for not
+  choosing them?
 - What is the impact of not doing this?
 
 # Unresolved questions
 
-What parts of the design are still to be determined?
+What parts of the design are still to be determined?

text/2017-12-22-read-pool.md

@@ -1,26 +1,28 @@
 # Summary
 
-This RFC proposes a new thread pool that supports async operations, which is called `ReadPool`. It
-is designed to be specifically used for all sorts of read operations like Kv Get, Kv Scan and
-Coprocessor Read to improve performance.
+This RFC proposes a new thread pool that supports async operations, which is
+called `ReadPool`. It is designed to be specifically used for all sorts of read
+operations like Kv Get, Kv Scan and Coprocessor Read to improve performance.
 
 # Motivation
 
-Currently, for all KV operations that stay inside `Storage`, they are executed on the same thread
-pool. This leads to bad operation isolation, i.e. heavy writes will cause slow reads. In fact, these
-read operations can be executed on other threads to be not blocked. For Coprocessor operations, we
-have an end-point worker thread to handle async snapshots. This is a bottleneck when there are heavy
-coprocessor requests.
+Currently, for all KV operations that stay inside `Storage`, they are executed
+on the same thread pool. This leads to bad operation isolation, i.e. heavy
+writes will cause slow reads. In fact, these read operations can be executed on
+other  threads to be not blocked. For Coprocessor operations, we have an
+end-point worker thread to handle async snapshots. This is a bottleneck when
+there are heavy coprocessor requests.
 
-By introducing a standalone thread pool that supports async operations (which is called ReadPool) in
-this RFC, we can fix both problems. For KV operations, read and write operations will be executed
-on different thread pools, so that they won't affect each other. For Coprocessor operations, since
-ReadPool supports async operations, the end-point worker is not necessary anymore and the bottleneck
-no longer exists.
+By introducing a standalone thread pool that supports async operations (which
+is called ReadPool) in this RFC, we can fix both problems. For KV operations,
+read and write operations will be executed on different thread pools, so that
+they won't affect each other. For Coprocessor operations, since ReadPool
+supports async operations, the end-point worker is not necessary anymore and
+the bottleneck no longer exists.
 
-In this RFC, there will be a ReadPool for KV operations and another ReadPool for Coprocessor
-operations, so that they won't block each other. In the future, it may be possible to merge
-them together.
+In this RFC, there will be a ReadPool for KV operations and another ReadPool
+for Coprocessor operations, so that they won't block each other. In the future,
+it may be possible to merge them together.
 
 # Detailed design
 
@@ -32,12 +34,13 @@ The ReadPool provides these features:
 
 3. Support max task threshold as a load control mechanism.
 
-The ReadPool can be implemented via 2 levels. The lower level is a new facility called
-`util::FuturePool`, which is a simple encapsulation over [CpuPool](https://docs.rs/futures-cpupool/)
-that supports feature 2. The higher level is `server::ReadPool`, which assembles multiple
-`FuturePool`s and supports features 1 and 3. In this way, `FuturePool` becomes a common facility
-that can be reused in the future to run other kinds of async operations that need contexts, not just
-limited to the scenario listed in this RFC.
+The ReadPool can be implemented via 2 levels. The lower level is a new facility
+called `util::FuturePool`, which is a simple encapsulation over
+[CpuPool](https://docs.rs/futures-cpupool/) that supports feature 2. The higher
+level is `server::ReadPool`, which assembles multiple `FuturePool`s and
+supports features 1 and 3. In this way, `FuturePool` becomes a common facility
+that can be reused in the future to run other kinds of async operations that
+need contexts, not just limited to the scenario listed in this RFC.
 
 ## FuturePool
 
@@ -49,8 +52,8 @@ pub trait Context: fmt::Debug + Send {
 }
 ```
 
-The `FuturePool` user can provide customized `impl Context` so that some code can be executed
-periodically within the context of the thread pool's thread.
+The `FuturePool` user can provide customized `impl Context` so that some code
+can be executed periodically within the context of the thread pool's thread.
 
 The `FuturePool` is defined as follows:
 
@@ -63,9 +66,10 @@ pub struct FuturePool<T: Context + 'static> {
 }
 ```
 
-The logic of whether to call `on_tick` is, when each task finishes running, we check how much
-time has elapsed. If the elapsed time since the last tick is longer than our tick interval, we call
-`on_tick`. In order to do so in a clean way, we can wrap this logic into a `ContextDelegator`:
+The logic of whether to call `on_tick` is, when each task finishes running, we
+check how much time has elapsed. If the elapsed time since the last tick is
+longer than our tick interval, we call `on_tick`. In order to do so in a clean
+way, we can wrap this logic into a `ContextDelegator`:
 
 ```rust
 struct ContextDelegator<T: Context> {
@@ -85,14 +89,15 @@ impl<T: Context> ContextDelegator<T> {
 }
 ```
 
-`FuturePool` users should pass a `Future` to the `FuturePool` to execute, just like `CpuPool`.
-However, to obtain access to the `Context` inside `Future`, the provided `Future` should be wrapped
-in a closure which provides access to the `Context` via the parameter. In the further, the parameter
-may live multiple `Future`s, which may run on different threads and different `Context`s. Thus, the
-parameter is a `Context` accessor instead of a specific `Context`.
+`FuturePool` users should pass a `Future` to the `FuturePool` to execute, just
+like `CpuPool`. However, to obtain access to the `Context` inside `Future`, the
+provided `Future` should be wrapped in a closure which provides access to the
+`Context` via the parameter. In the further, the parameter may live multiple
+`Future`s, which may run on different threads and different `Context`s. Thus,
+the parameter is a `Context` accessor instead of a specific `Context`.
 
-As a result, this RFC further introduces the following struct, which provides an access to the
-current `Context` based on running thread:
+As a result, this RFC further introduces the following struct, which provides
+an access to the current `Context` based on running thread:
 
 ```rust
 pub struct ContextDelegators<T: Context> {
@@ -106,7 +111,8 @@ impl<T: Context> ContextDelegators<T> {
 }
 ```
 
-The `FuturePool` provides `spawn` interface to execute a `Future` while providing
+The `FuturePool` provides `spawn` interface to execute a `Future` while
+providing
 `ContextDelegators`:
 
 ```rust
@@ -138,8 +144,8 @@ pub struct ReadPool<T: Context + 'static> {
 }
 ```
 
-It also provides an interface similar to `FuturePool::spawn`, which specifies the priority and
-returns an error when `FuturePool` is full:
+It also provides an interface similar to `FuturePool::spawn`, which specifies
+the priority and returns an error when `FuturePool` is full:
 
 ```rust
 pub enum Priority {
@@ -177,17 +183,18 @@ impl<T: futurepool::Context + 'static> ReadPool<T> {
 
 # Drawbacks
 
-The `on_tick` implementation in `FuturePool` is not perfect. It is driven by task completion, which
-means it will not be executed when there is no task. This is acceptable since we are going to use
-`on_tick` to report metrics.
+The `on_tick` implementation in `FuturePool` is not perfect. It is driven by
+task completion, which means it will not be executed when there is no task.
+This is acceptable since we are going to use `on_tick` to report metrics.
 
 # Alternatives
 
-We can implement our own future pool instead of utilizing `CpuPool`. In this way, we can have a true
-`on_tick`. However, this is complex and is not a necessary feature we need.
+We can implement our own future pool instead of utilizing `CpuPool`. In this
+way, we can have a true `on_tick`. However, this is complex and is not a
+necessary feature we need.
 
-We can implement our own async model instead of utilizing `Future`. However, there is no benefits
-compared to the current solution.
+We can implement our own async model instead of utilizing `Future`. However,
+there is no benefits compared to the current solution.
 
 # Unresolved questions