Add std::sync::mpsc::Receiver::recv_deadline() #45969
Conversation
Essentially renames recv_max_until to recv_deadline (mostly copying recv_timeout
documentation). This function is useful to avoid the often unnecessary call to
Instant::now in recv_timeout (e.g. when the user already has a deadline). A
concrete example would be something along those lines:
```rust
use std::sync::mpsc::Receiver;
use std::time::{Duration, Instant};
/// Reads a batch of elements
///
/// Returns as soon as `max_size` elements have been received or `timeout` expires.
fn recv_batch_timeout<T>(receiver: &Receiver<T>, timeout: Duration, max_size: usize) -> Vec<T> {
recv_batch_deadline(receiver, Instant::now() + timeout, max_size)
}
/// Reads a batch of elements
///
/// Returns as soon as `max_size` elements have been received or `deadline` is reached.
fn recv_batch_deadline<T>(receiver: &Receiver<T>, deadline: Instant, max_size: usize) -> Vec<T> {
let mut result = Vec::new();
while let Ok(x) = receiver.recv_deadline(deadline) {
result.push(x);
if result.len() == max_size {
break;
}
}
result
}
```
kennytm
added
S-waiting-on-review
|
r? @Kimundi |
|
Thanks for the PR! We’ll periodically check in on it to make sure that @Kimundi or someone else from the @rust-lang/libs team reviews it soon. |
|
Thanks for the feedback! |
|
Thanks for the PR @ia0! In general we never land new APIs as Overall I like the idea of |
kennytm
added
S-waiting-on-author
kennytm
added
S-waiting-on-review
|
Thanks for your review @alexcrichton! I created #46316 to track a possible API convention for blocking-, timeout-, and deadline-related functions. I switched to an unstable feature. And actually I wonder if I shouldn't have done the same for #45506 then. |
|
Awesome, thanks @ia0! I'll comment on that soon. It looks like tests are failing though? I think the doctests here will need to be tagged with the |
|
Indeed, I forgot to update the tests. It should be fixed now (at least locally |
|
📌 Commit 8e025d8 has been approved by |
|
⌛ Testing commit 8e025d8 with merge 9546a1bc65fea0eb3d9e2c8d98508d566f230eff... |
|
💔 Test failed - status-travis |
|
Thanks for the review and explanation about impl stabilization. The homu test seems to have failed because the build of LLVM for x86_64-apple-darwin seems to fail because The other tests seem to have been cancelled. |
|
@bors retry — travis-ci/travis-ci#8821 |
Add std::sync::mpsc::Receiver::recv_deadline()
Essentially renames recv_max_until to recv_deadline (mostly copying recv_timeout
documentation). This function is useful to avoid the often unnecessary call to
Instant::now in recv_timeout (e.g. when the user already has a deadline). A
concrete example would be something along those lines:
```rust
use std::sync::mpsc::Receiver;
use std::time::{Duration, Instant};
/// Reads a batch of elements
///
/// Returns as soon as `max_size` elements have been received or `timeout` expires.
fn recv_batch_timeout<T>(receiver: &Receiver<T>, timeout: Duration, max_size: usize) -> Vec<T> {
recv_batch_deadline(receiver, Instant::now() + timeout, max_size)
}
/// Reads a batch of elements
///
/// Returns as soon as `max_size` elements have been received or `deadline` is reached.
fn recv_batch_deadline<T>(receiver: &Receiver<T>, deadline: Instant, max_size: usize) -> Vec<T> {
let mut result = Vec::new();
while let Ok(x) = receiver.recv_deadline(deadline) {
result.push(x);
if result.len() == max_size {
break;
}
}
result
}
```
kennytm
added
S-waiting-on-bors
Essentially renames recv_max_until to recv_deadline (mostly copying recv_timeout
documentation). This function is useful to avoid the often unnecessary call to
Instant::now in recv_timeout (e.g. when the user already has a deadline). A
concrete example would be something along those lines: