================
@@ -223,6 +220,61 @@ TEST_F(MainLoopTest, ManyPendingCallbacks) {
ASSERT_TRUE(loop.Run().Success());
}
+TEST_F(MainLoopTest, CallbackWithTimeout) {
+ MainLoop loop;
+ loop.AddCallback([](MainLoopBase &loop) { loop.RequestTermination(); },
+ std::chrono::seconds(2));
+ auto start = std::chrono::steady_clock::now();
+ ASSERT_THAT_ERROR(loop.Run().takeError(), llvm::Succeeded());
+ EXPECT_GE(std::chrono::steady_clock::now() - start, std::chrono::seconds(2));
----------------
labath wrote:
The representation is "an integer" but to interpret it, you need to know the
resolution of the steady_clock on windows (arm). That appears to be
nanoseconds, which means this value is `0x77354edc/1e9 = 1.9999823000000001`
seconds, which means that the callback runs sooner than it should have. I think
I know the reason. Lemme whip up a patch real quick.
https://github.com/llvm/llvm-project/pull/112895
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
