CondVar wait functions accepting a closure #47960
Labels
A-concurrency
Area: Concurrency
B-unstable
Blocker: Implemented in the nightly compiler and unstable.
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
|
Generally, for small features, we just take PRs, and for big ones, issues. I'm not sure if @rust-lang/libs considers this a small or large feature. |
|
This seems small enough for a direct PR, yes. |
|
Will prepare it. Still a little new to rust. Would the callback be Fn or FnMut? |
|
|
cuviper
added
A-concurrency
dtolnay
added
C-feature-accepted
Manishearth
added a commit
to Manishearth/rust
that referenced
this issue
Feb 25, 2018
Add Condvar APIs not susceptible to spurious wake Provide wait_until and wait_timeout_until helper wrappers that aren't susceptible to spurious wake. Additionally wait_timeout_until makes it possible to more easily write code that waits for a fixed amount of time in face of spurious wakes since otherwise each user would have to do math on adjusting the duration. Implements rust-lang#47960.
kennytm
added a commit
to kennytm/rust
that referenced
this issue
Feb 25, 2018
Add Condvar APIs not susceptible to spurious wake Provide wait_until and wait_timeout_until helper wrappers that aren't susceptible to spurious wake. Additionally wait_timeout_until makes it possible to more easily write code that waits for a fixed amount of time in face of spurious wakes since otherwise each user would have to do math on adjusting the duration. Implements rust-lang#47960.
jonas-schievink
added
C-tracking-issue
|
Is anything preventing stabilization of this? |
|
@rust-lang/libs can I nominate this for stabilization? We've been using these in the code base at my job for a while, and we'd love to move to stable Rust soon without needing to shim these out. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Pretty common for conditional variable classes to provide wait variants that accept a closure that returns a boolean indicating whether or not the condition has been satisfied. This would be a pretty nice ergonomic improvement to using CondVar. Something like
cvar.wait_until(lock, || { some condition }). Even more useful would be await_timeout_untilwhich would avoid the need to keep track of elapsed time if the condition variable might get notified several times before the condition is met.The text was updated successfully, but these errors were encountered: