Remove a flaky got_timeout assert from two channel tests#153534
Remove a flaky got_timeout assert from two channel tests#153534Zalathar wants to merge 1 commit intorust-lang:mainfrom
got_timeout assert from two channel tests#153534Conversation
In CI, the receiver thread can be descheduled for a surprisingly long time, so there's no guarantee that a timeout actually occurs.
rustbot
added
S-waiting-on-review
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
| }); | ||
|
|
||
| let mut recv_count = 0; | ||
| let mut got_timeout = false; |
There was a problem hiding this comment.
I wonder why not just make the sender thread have a while loop on a shared atomic value (like an Arc<AtomicBool>) that yields itself through thread::yield_now? Or I'm wondering if we could also use a shared Condvar that waits in the sender thread and the receiver thread is the one that sends a notification? That way we can guarantee that our receiver thread experiences a RecvTimeoutError::Timeout error after 10 ms and either set the atomic value to a state that the while loop from the sender thread will stop looping on or the sender thread just resumes its iteration in the for loop upon receiving a notification.
4 participants
In CI, the receiver thread can be descheduled for a surprisingly long time, so there's no guarantee that a timeout actually occurs.
One of these tests actually failed in #153387 (comment).
Earlier failures:
oneshottests #152878