microsoft
Implement LWG-4301: condition_variable{_any}::wait_{for, until} should take timeout by value
Notes and questions for review:
The behavior of most overloads stays identical, as they are all implemented in terms of other functions from the wait_{for, until} family, just with relative time converted to absolute or vice versa. In such cases, const & was bound to temporary objects and thus possible modifications by the user were ignored. For this reason, some changes are not testable; however, I have provided the tests for completeness.
I have kept all absolute/relative timeouts as const arguments. It appears that some parts of the STL adhere to the "const everything" guideline, so I hope it is valid.
While preparing the tests, I have found a difference in the behavior of MSVC and clang/GCC. Details are in https://github.com/microsoft/STL/issues/5859#issuecomment-3554134353
I have incorporated @frederick-vs-ja 's suggestions. However, regarding the failing tests, I am baffled a little. I can't reliably reproduce the failure - I reproduced it twice using stl-lit, but never with debugger attached.
I will try to dig deeper into it, but should anyone find a problem, I'd be most grateful.
Are there timing assumptions in your tests? Whenever exercising timeout-related code, we need to be very careful to write tests such that they always succeed, regardless of how quickly or slowly operations complete, limited only by the Standard's guarantees. We've had to fix/skip a lot of tests containing assumptions like "surely this will complete in 100ms" or "surely this will never take 2 seconds".
Are there timing assumptions in your tests?
It is GH_000685_condition_variable_any test that fails:
std :: tests/GH_000685_condition_variable_any:12
std :: tests/GH_000685_condition_variable_any:29
It doesn't seem to have any timing assumptions. Maybe no-spurious-unblock assumption though, the test might have it.
Are there timing assumptions in your tests? Whenever exercising timeout-related code, we need to be very careful to write tests such that they always succeed, regardless of how quickly or slowly operations complete, limited only by the Standard's guarantees. We've had to fix/skip a lot of tests containing assumptions like "surely this will complete in 100ms" or "surely this will never take 2 seconds".
I have sprinkled the test with some assertions and I have pinpointed the issue - exactly as you suggested. I assumed the child thread is fired in less than 100 ms, whereas in reality, I have observed some very high delays (e.g. 5 seconds). I will add some startup synchronization to ensure the child thread is properly started; it is not very elegant in C++11 (without std::latch) though...
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.