Stabilize Condvar::wait_while and wait_timeout_while (previously wait_until, wait_timeout_until) #67076
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
jonas-schievink
added
the
relnotes
jonas-schievink
added
the
needs-fcp
Centril
added
the
T-libs-api
|
r? @dtolnay for commencing FCP here, this is proposing to stabilize the following APIs, implemented in #47970. impl Condvar {
fn wait_until<'a, T, F>(&self, mut guard: MutexGuard<'a, T>,
mut condition: F)
-> LockResult<MutexGuard<'a, T>>
where F: FnMut(&mut T) -> bool;
fn wait_timeout_until<'a, T, F>(&self, mut guard: MutexGuard<'a, T>,
dur: Duration, mut condition: F)
-> LockResult<(MutexGuard<'a, T>, WaitTimeoutResult)>
where F: FnMut(&mut T) -> bool;
}For some background, these APIs mirror the ones present in C++ (though there they are through overloads on
Before stabilization, we would likely want to update the documentation to avoid the language around ignoring spurious wakeups (which is not true; the closure is still run). |
|
I am on board with these APIs. These are practically always what you want -- there are few use cases for directly using impl Condvar {
fn wait_until<'a, T, F>(
&self,
guard: MutexGuard<'a, T>,
condition: F,
) -> LockResult<MutexGuard<'a, T>>
where
F: FnMut(&mut T) -> bool;
fn wait_timeout_until<'a, T, F>(
&self,
guard: MutexGuard<'a, T>,
dur: Duration,
condition: F,
) -> LockResult<(MutexGuard<'a, T>, WaitTimeoutResult)>
where
F: FnMut(&mut T) -> bool;
}@rfcbot fcp merge |
|
Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
|
@rfcbot concern _until naming Using the name |
|
Good call. Perhaps |
|
Our uses look like approximately like: I think these are about equally readable as: (Or for the last one we could flip the meaning of the boolean and rename it to |
|
That looks all right to me. I would be prepared to accept this stabilization after a rename to wait_while / wait_timeout_while. |
|
Added a commit to rename both methods (flipping the meaning of the condition) and update all docs and tests. |
mbrubeck
changed the title
|
☔ The latest upstream changes (presumably #67540) made this pull request unmergeable. Please resolve the merge conflicts. |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
mbrubeck
changed the title
|
Why hasn't this entered final comment period yet? Does the concern need to be marked resolved? |
|
@rfcbot resolved _until naming |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
Shouldn't renaming usually mean we wait a bit for further feedback before stabilizing? |
|
Not always - sometimes the thing we learn from the FCP is that we want to make a small change (like wait_until -> wait_while), but otherwise feel confident enough that we don't need to wait another N months to stabilize. |
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
|
@bors r+ |
|
📌 Commit 98d054a has been approved by |
bors
added
S-waiting-on-bors
Stabilize Condvar::wait_while and wait_timeout_while (previously wait_until, wait_timeout_until) Closes #47960.
|
☀️ Test successful - checks-azure |
Closes #47960.