Merge pull request Kotlin#5 from qiaoyuang/master

将《基础》和《取消与超时》重新review了一遍，修正了错别字和使用不当的标点符号

Author: hltj

docs/basics.md

@@ -211,19 +211,19 @@ World!
 这里还有一些东西我们期望的写法被使用在协程的练习中。
 当我们使用 `GlobalScope.launch` 时我们创建了一个最高优先级的协程。甚至，虽然它是轻量级的，
 但是它在运行起来的时候仍然消耗了一些内存资源。甚至如果我们失去了一个对新创建的协程的引用，
-它仍然会继续运行。如果一段代码在协程中挂起(举例来说，我们错误的<!--
--->延迟了太长时间)，如果我们启动了太多的协程，是否会导致内存溢出？
+它仍然会继续运行。如果一段代码在协程中挂起（举例来说，我们错误的<!--
+-->延迟了太长时间），如果我们启动了太多的协程，是否会导致内存溢出？
 如果我们手动引用所有的协程和 [join][Job.join] 是非常容易出错的。
 
 这有一个更好的解决办法。我们可以在你的代码中使用结构性并发。
-用来代替在 [GlobalScope] 中启动协程，就像我们使用线程时那样(线程总是全局的)，
+用来代替在 [GlobalScope] 中启动协程，就像我们使用线程时那样（线程总是全局的），
 我们可以在一个具体的作用域中启动协程并操作。
 
-在我们的例子中, 我们有一个被转换成使用[runBlocking]的协程构建器的`main`函数
-每一个协程构建器, 包括`runBlocking`, 添加了一个实例在[CoroutineScope]作用域的代码块中.
-我们可以在一个协程还没有明确的调用`join`之前在这个作用域内启动它们, 因为一个外部的协程
-(我们的例子中的`runBlocking`) 没有在所有的协程在它们的作用域内启动完成后执行<!--
--->完毕, 从而, 我们可以使我们的例子更简单:
+在我们的例子中, 我们有一个被转换成使用[runBlocking]的协程构建器的 `main` 函数
+每一个协程构建器, 包括 `runBlocking` , 添加了一个实例在 [CoroutineScope] 作用域的代码块中.
+我们可以在一个协程还没有明确的调用 `join` 之前在这个作用域内启动它们, 因为一个外部的协程
+（我们的例子中的 `runBlocking` ）没有在所有的协程在它们的作用域内启动完成后执行<!--
+-->完毕，从而，我们可以使我们的例子更简单：
 
 <div class="sample" markdown="1" theme="idea" data-min-compiler-version="1.3">
 
@@ -252,7 +252,7 @@ World!
 除了由不同的构建器提供的协程作用域，也是可以使用 [coroutineScope] 构建器来声明你自己<!--
 -->的作用域。它启动了一个新的协程作用域并且在所有子协程执行结束后并没有执行<!--
 -->完毕。[runBlocking] 和 [coroutineScope] 主要的不同之处在于后者在等待所有的子协程<!--
--->执行完毕时并没有使当前线程阻塞.
+-->执行完毕时并没有使当前线程阻塞。
 
 <div class="sample" markdown="1" theme="idea" data-min-compiler-version="1.3">
 
@@ -292,10 +292,10 @@ Coroutine scope is over
 
 ### 提取函数重构
 
-让我们在 `launch { ... }` 中提取代码块并分离到另一个函数中. 当你
-在这段代码上展示"提取函数"函数的时候, 你的到了一个新的函数并用 `suspend` 修饰.
+让我们在 `launch { ... }` 中提取代码块并分离到另一个函数中。当你<!--
+-->在这段代码上展示“提取函数”函数的时候, 你得到了一个新的函数并用 `suspend` 修饰。
 这是你的第一个 _挂起函数_ 。挂起函数可以像一个普通的函数一样使用内部协程，但是它们拥有一些额外的特性，反过来说，
-使用其它的挂起函数, 比如这个例子中的 `delay`，可以使协程暂停执行。
+使用其它的挂起函数，比如这个例子中的 `delay`，可以使协程暂停执行。
 
 <div class="sample" markdown="1" theme="idea" data-min-compiler-version="1.3">
 
@@ -325,8 +325,8 @@ World!
 
 
 但是如果提取函数包含了一个调用当前作用域的协程构建器？
-在这个例子中仅仅使用 `suspend` 来修饰提取出来的函数是不够的. 在 `CoroutineScope` 调用 `doWorld` 方法
-是一种解决方案, 但它并非总是适用, 因为它不会使API看起来更清晰。
+在这个例子中仅仅使用 `suspend` 来修饰提取出来的函数是不够的。在 `CoroutineScope` 调用 `doWorld` 方法
+是一种解决方案，但它并非总是适用，因为它不会使API看起来更清晰。
 惯用的解决方法是使 `CoroutineScope` 在一个类中作为一个属性并包含一个目标函数，
 或者使它外部的类实现 `CoroutineScope` 接口。
 作为最后的手段，[CoroutineScope(coroutineContext)][CoroutineScope()] 也是可以使用的，但是这样的结构是不安全的

docs/cancellation-and-timeouts.md

@@ -84,7 +84,7 @@ main: Now I can quit.
 
 ### 取消协作
 
-协程的取消是 _协作_ 的。一段协程代码必须合作才能被取消。
+协程的取消是 _协作_ 的。一段协程代码必须协作才能被取消。
 所有 `kotlinx.coroutines` 中的挂起函数都是 _可被取消的_ 。它们检查协程的取消，
 并在取消时抛出 [CancellationException]。 然而，如果协程正在执行<!--
 -->计算任务，并且没有检查取消的话，那么它是不能被取消的，就如如下示例<!--
@@ -331,7 +331,7 @@ Exception in thread "main" kotlinx.coroutines.TimeoutCancellationException: Time
 -->在被取消的协程中 `CancellationException` 被认为是协程执行结束的正常原因。 
 然而，在这个示例中我们在 `main` 函数中正确地使用了 `withTimeout`。
 
-由于取消只是一个例外, 所有的资源都使用常用的方法来关闭。
+由于取消只是一个例外，所有的资源都使用常用的方法来关闭。
 如果你需要做一些各类使用超时的特别的额外操作，可以使用类似 [withTimeout]
 的 [withTimeoutOrNull] 函数，并把这些会超时的代码包装在 `try {...} catch (e: TimeoutCancellationException) {...}`
 代码块中，而 [withTimeoutOrNull] 通过返回 `null` 来进行超时操作，从而替代抛出一个异常：