|
|
@ -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 的巨大陷阱
|
|
|
|