Update multi-threads.md

fix typo
pull/1345/head
ShoreCN 12 months ago committed by GitHub
parent cad3135151
commit bb3acaef9a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -527,7 +527,7 @@ impl Worker {
一旦获取到锁里的内容 `mpsc::Receiver<Job>>` 后,就可以调用其上的 `recv` 方法来接收消息,依然是一个 `unwrap`,原因在于持有发送端的线程可能会被关闭,这种情况下直接 `panic` 也是不错的。 一旦获取到锁里的内容 `mpsc::Receiver<Job>>` 后,就可以调用其上的 `recv` 方法来接收消息,依然是一个 `unwrap`,原因在于持有发送端的线程可能会被关闭,这种情况下直接 `panic` 也是不错的。
`recv` 的调用过程是阻塞的,意味着若没有任何任务,那当前的调用线程将一直等待,直到接收到新的任务。`Mutex<T>` 可以同一个任务只会被一个 Worker 获取,不会被重复执行。 `recv` 的调用过程是阻塞的,意味着若没有任何任务,那当前的调用线程将一直等待,直到接收到新的任务。`Mutex<T>` 可以保证同一个任务只会被一个 Worker 获取,不会被重复执行。
```shell ```shell
$ cargo run $ cargo run
@ -570,7 +570,7 @@ Worker 2 got a job; executing.
终于,程序如愿运行起来,我们的线程池可以并发处理任务了!从打印的数字可以看到,只有 4 个线程去执行任务,符合我们对线程池的要求,这样再也不用担心系统的线程资源会被消耗殆尽了! 终于,程序如愿运行起来,我们的线程池可以并发处理任务了!从打印的数字可以看到,只有 4 个线程去执行任务,符合我们对线程池的要求,这样再也不用担心系统的线程资源会被消耗殆尽了!
> 注意: 于缓存的考虑,有些浏览器会对多次同样的请求进行顺序的执行,因此你可能还是会遇到访问 `/sleep` 后,就无法访问另一个 `/sleep` 的问题 :( > 注意: 于缓存的考虑,有些浏览器会对多次同样的请求进行顺序的执行,因此你可能还是会遇到访问 `/sleep` 后,就无法访问另一个 `/sleep` 的问题 :(
## while let 的巨大陷阱 ## while let 的巨大陷阱

Loading…
Cancel
Save