-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
CondVar wait functions accepting a closure #47960
Copy link
Copy link
Closed
Labels
A-concurrencyArea: ConcurrencyArea: ConcurrencyB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-concurrencyArea: ConcurrencyArea: ConcurrencyB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
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.