Closed frolosofsky closed 5 years ago
utACK cfe3839413639ad83ba95dd238b4afaa71671790
It failed again right in this PR.
Entering test module "Unit-e Test Suite"
test/waiter_tests.cpp(14): Entering test suite "waiter_tests"
test/waiter_tests.cpp(29): Entering test case "wait_and_wake_test"
test/waiter_tests.cpp(22): fatal error: in "waiter_tests/wait_and_wake_test": critical check now < wait_until has failed
Replaced yield
with sleep_for(millisecond)
as first one produces 100% load on the core, maybe it affects tests being run with hight parallelism. I still don't see any deadlock in the code, in fact it has simplified to trivial condition variable wrapper. This fact makes me think we don't need this test at all, as it is checking C++ stdlib rather custom logic.
I agree that proposer::Waiter
is a trivial wrapper over std::condition_variable
, and would be ok with removing the test.
Edit: ....and it failed again, even with the sleep
. Either there's something wrong with the C++ stdlib on Windows, or there's a deadlock in the test we don't see.
Ok this guy flaked again but differently. I think, it's nice to delete them completely. Reasoning in PR description and https://github.com/dtr-org/unit-e/pull/973#issuecomment-483195256.
@scravy @cmihai @thothd re-review it please.
Edit: ....and it failed again, even with the sleep. Either there's something wrong with the C++ stdlib on Windows, or there's a deadlock in the test we don't see.
Last time it failed differently: in one of the test scenarios where we expected the thread to wake up in 10 seconds. The fact that it didn't fail in 60 seconds assertion tells us that it has been actually woken up but after more than 10 seconds.
So, it was neither a bug in stdlib nor dead lock. In this particular time at least.
There is no "windows C++ stdlib", we use mingw compiler and I guess it uses gcc C++ stdlib. Windows doesn't ship C++ stdlib at all AFAIK.
Fixes #933.