为什么变量绑定会影响循环体内的生命周期?
Why does variable binding affect lifetime inside a loop body?
在 "The Rust Programming Language" 和 chapter 20 中,您将完成构建简单的多线程 Web 服务器的练习。在练习中,您使用单个 std::sync::mpsc
通道。工作线程都访问一个接收器,它包含如下:Arc<Mutex<mpsc::Receiver<Message>>>
.
如果我们这样写工作线程:
let thread = thread::spawn(move || loop {
match receiver.lock().unwrap().recv().unwrap() {
Message::NewJob(job) => {
println!("Worker {} got a job; executing.", id);
job.call_box();
println!("Worker {} job complete.", id);
}
Message::Terminate => {
println!("Worker {} was told to terminate.", id);
break;
}
};
println!("hello, loop");
});
然后我们没有实现并发,显然 worker 持有我认为的互斥锁,因为在前一个工作完成之前,没有 worker 能够完成另一个工作。然而,如果我们简单地把它改成这样(书中如何显示代码):
let thread = thread::spawn(move || loop {
let message = receiver.lock().unwrap().recv().unwrap();
match message {
Message::NewJob(job) => {
println!("Worker {} got a job; executing.", id);
job.call_box();
println!("Worker {} job complete.", id);
}
Message::Terminate => {
println!("Worker {} was told to terminate.", id);
break;
}
};
println!("hello, loop");
});
然后一切正常。如果你发出 5 个请求,你会看到每个线程立即得到一个。并发!
问题是 "why does variable binding affect lifetime"(我假设这就是原因)。或者,如果没有,那么我错过了一些东西,那是什么?!这本书本身谈到了你如何不能用 while let Ok(job) = receiver.lock().unwrap().recv() {
实现工作循环,因为锁的范围,但显然甚至 inside 循环中也有龙。
因为在 Rust 中,"resource acquisition is initialization"。
具体receiver.lock()
returns 初始化时获取锁,删除时释放锁的类型
在您的第一个示例中,MutexGuard
的生命周期延伸到 match
语句的末尾,因此在调用 job.call_box()
时将持有锁。
match receiver.lock().unwrap().recv().unwrap() {
// ...
};
// `MutexGuard` is dropped and lock is released here
在你的第二个例子中,锁守卫只保持活动足够长的时间来从你的消息队列中读取一条消息;锁保护器在语句末尾被删除,并且在输入 match
之前释放锁。
let message = receiver.lock().unwrap().recv().unwrap();
// `MutexGuard` is dropped and lock is released here
match message {
在 "The Rust Programming Language" 和 chapter 20 中,您将完成构建简单的多线程 Web 服务器的练习。在练习中,您使用单个 std::sync::mpsc
通道。工作线程都访问一个接收器,它包含如下:Arc<Mutex<mpsc::Receiver<Message>>>
.
如果我们这样写工作线程:
let thread = thread::spawn(move || loop {
match receiver.lock().unwrap().recv().unwrap() {
Message::NewJob(job) => {
println!("Worker {} got a job; executing.", id);
job.call_box();
println!("Worker {} job complete.", id);
}
Message::Terminate => {
println!("Worker {} was told to terminate.", id);
break;
}
};
println!("hello, loop");
});
然后我们没有实现并发,显然 worker 持有我认为的互斥锁,因为在前一个工作完成之前,没有 worker 能够完成另一个工作。然而,如果我们简单地把它改成这样(书中如何显示代码):
let thread = thread::spawn(move || loop {
let message = receiver.lock().unwrap().recv().unwrap();
match message {
Message::NewJob(job) => {
println!("Worker {} got a job; executing.", id);
job.call_box();
println!("Worker {} job complete.", id);
}
Message::Terminate => {
println!("Worker {} was told to terminate.", id);
break;
}
};
println!("hello, loop");
});
然后一切正常。如果你发出 5 个请求,你会看到每个线程立即得到一个。并发!
问题是 "why does variable binding affect lifetime"(我假设这就是原因)。或者,如果没有,那么我错过了一些东西,那是什么?!这本书本身谈到了你如何不能用 while let Ok(job) = receiver.lock().unwrap().recv() {
实现工作循环,因为锁的范围,但显然甚至 inside 循环中也有龙。
因为在 Rust 中,"resource acquisition is initialization"。
具体receiver.lock()
returns 初始化时获取锁,删除时释放锁的类型
在您的第一个示例中,MutexGuard
的生命周期延伸到 match
语句的末尾,因此在调用 job.call_box()
时将持有锁。
match receiver.lock().unwrap().recv().unwrap() {
// ...
};
// `MutexGuard` is dropped and lock is released here
在你的第二个例子中,锁守卫只保持活动足够长的时间来从你的消息队列中读取一条消息;锁保护器在语句末尾被删除,并且在输入 match
之前释放锁。
let message = receiver.lock().unwrap().recv().unwrap();
// `MutexGuard` is dropped and lock is released here
match message {